How are alternate superblocks repaired?

[Theodore Tso]

On Sat, Sep 29, 2007 at 03:29:13AM -0400, Thomas Watt wrote:
> The only field not updated was the Filesystem state field. So, all
> of the backup superblocks remain "not clean" and are now at least a
> lot closer to being consistent with the primary superblock - just
> not quite there yet as far as being usable in case the primary
> superblock gets hosed.

That's by design.  The backup superblock always have the filesystem
state set to "not clean".  They are written out that way!  Keep in
mind that kernel does *not* update the backup superblocks under normal
operations.  So by definition, fields such as the free blocks, free
inodes, last mount time, mount count, are always going to be out of
date in the backup superblocks.  AND THAT'S OK.

The whole point of the backup superblocks is to have an extra copy of
the fundamental filesystem parameters --- the blocksize, the number of
inodes per block group, the block group size, the location of the
inode table and the allocation bitmaps, and so on.  That doesn't
change under normal circumstances except when the filesystem is
resized, so that's why it's OK for the kernel to not bother to update
them.  

If the primary superblock is destroyed, e2fsck will use the backup
superblocks to reconstruct the filesystem, and in the process of
reconstructing the filesystem, it will update the free blocks, free
inodes, and the other more transient portions of the filesystem.

I'm not sure why you are so concerned about keeping every last field
in the backup superblocks identical to that of the primary.  There are
lots of good reasons why they are not the same; the less they are
modified, more likely they won't get corrupted or otherwise messed up.
(For example, in addition to making the umount operation take a lot
longer, the fact that the kernel never writes the backup superblocks
means that we don't have to worry about what happens if the in-memory
copy of the superblocks are corrupted --- say because the system
administrator was too cheap to use ECC memory --- even if they are
written to the primaries, the backups will still be OK for e2fsck to
use for recovery purposes.)

						- Ted