How are alternate superblocks repaired?

[Theodore Tso]

On Fri, Sep 28, 2007 at 01:18:16AM -0400, Thomas Watt wrote:
> The Maximum mount count is 30, and I have no reason to believe that
> e2fsck has ever been run against this particular FC3 ext filesystem.
> I have every reason to believe, however, that fsck has been run on
> occasion when I either boot the FC3 system manually and the mount
> count is over 30 or when I experience the situation where the
> ext_attr goes missing and I then manually boot the system when it is
> not clean in the primary superblock.  The system was created at the
> end of March, 2005 and as you can see from the differences the
> backup superblock(s) have never even been touched after their
> creation.
> 
> What parameters do you suggest be used when e2fsck is run to repair
> the backup superblocks?

Hi Tom, 

There are a couple of things going on here.  First of all, out of
general paranoia, neither e2fsck nor the kernel touch backup
superblocks out of general paranoia.  Most of the changes that you
pointed out between the primary and backup superblocks are no big
deal, and can easily be regenerated by e2fsck.  The one exception to
is the feature bitmasks.  Most of the time it's only tune2fs which
makes changes to the feature compatibility bitmasks.  

Unfortunately, the kernel does make some changes "behind the user's
back"; and one of them is the ext_attr feature flag.  So thanks for
pointing that out, and I'll have to make an enhacement to e2fsck to
detect if the backup superblock's compatibility flags are different,
and if so, to update the backup superblocks.

For now, you can work around this and force an update to the backup
superblocks by running the following command as root:

e2label /dev/hdXXX "`e2label /dev/hdXXX`"

This reads out the label from the filesystem, and thes sets the label
to its current value.  This will force a copy from the primary to the
backup superblocks.

Regards,

							- Ted