I've been looking through the code in fs/ext2, mostly super.c, and I'm a
bit confused as to how the kernel handles updating all of the superblock
copies on the disk.
I haven't really worked much with the kernel, but it appears that the
ext2 code essentially does a "mmap" of the disk blocks (using bread()),
and leaves it up to some other kernel functions to flush the data to
disk as it is changed and/or marked dirty.
However, it appears that only the primary superblock and group descriptors
are mapped into memory. The function ext2_put_super() updates the "mmapped"
superblock and group descriptors, but ext2_write_super()/ext2_commit_super()
doesn't bother writing anything into the backup superblocks or backup
group descriptors.
What happens if the primary SB is corrupt? Is it up to e2fsck to take the
user-specified superblock and update all of the superblock fields like
free blocks, free inodes, and all of the group descriptors in the backup
group? Am I missing something elsewhere in the code which keeps the backup
blocks up-to-date on the disk, either in "real time", or at unmount time?
Race conditions aside, if a disk block is mmaped into the kernel (via bread()
into a buffer_head), and a user-space process writes to this block on disk,
what is the end result? Does the kernel keep a unified cache between kernel
and user I/O? Will access from the kernel now reflect the new data that was
written to disk by the user process, or does something have to happen before
the kernel becomes aware of the new data?
Cheers, Andreas
--
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert
