[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How are alternate superblocks repaired?



Hi Ted,

Thanks for the workaround, I appreciate it very much.

Cheers,

-- Tom

-----Original Message-----
>From: Theodore Tso <tytso mit edu>
>Sent: Sep 28, 2007 2:55 PM
>To: Thomas Watt <tango tiac net>
>Cc: Andreas Dilger <adilger clusterfs com>, ext3-users redhat com
>Subject: Re: How are alternate superblocks repaired?
>
>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
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]