Hi Ted, I just wanted to give you some feedback on running the e2label command to fix the problem of backup superblock inconsistency with the primary superblock. Since Linux filesystem name labels are optional and my filesystem volume name was not set, I wondered if that would make a difference. It did not. I did not opt to set a label, but just followed your suggested command. The following fields were updated: Filesystem features Free blocks Free inodes Last mount time Last write time Mount count Last checked Next check after 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. At this point I don't suppose there is anyway for e2fsck to make the backup superblocks "clean" (i.e. only when the primary is clean) until your enhancement gets released. It was fairly easy to make this assessment using the script I wrote to dump all of the superblocks and make the comparisons of before and after superblock states. Checking the result was the easy part. I want to make a few changes, test them out and donate the script to the e2fsprogs project. It should make it just a little bit easier for system administrators to keep an eye on the backup superblocks, and you also might find it useful in testing your enhancement to e2fsck. The only caveat is that the script has not been tested on ext2/ext3 filesystems with blocksizes of 1024 or 2048s. There are provisions for 1024 and 2048 blocksized sytsems - that's the speculative part of the script that needs testing - assumptions always need testing/challenging - right? :) I hope this feedback helps in your enhancement efforts to e2fsck. Regards, -- Tom -----Original Message----- >From: Theodore Tso <tytso@xxxxxxx> >Sent: Sep 28, 2007 2:55 PM >To: Thomas Watt <tango@xxxxxxxx> >Cc: Andreas Dilger <adilger@xxxxxxxxxxxxx>, ext3-users@xxxxxxxxxx >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 > _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
