[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: How are alternate superblocks repaired?
- From: Thomas Watt <tango tiac net>
- To: Theodore Tso <tytso mit edu>
- Cc: Andreas Dilger <adilger clusterfs com>, ext3-users redhat com
- Subject: Re: How are alternate superblocks repaired?
- Date: Fri, 28 Sep 2007 17:28:18 -0400 (GMT-04:00)
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]