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

Re: How are alternate superblocks repaired?



Hi Ted,

Ok, I think I understand now.  I was assuming the backup superblocks played a role without the intervention of using e2fsck and were ready to be used in a standby mode when the primary superblock gets corrupted.  But, of course, there is a very real reason to be cautious when the kernel may do things unknown to users.

My point-of-view was more flavored by something like the Multics structure marking that kept backup data structures free from damage.  It is clear there is another strategy at work here, but one that is workable and sufficient for the ext2/ext3 filesystem.

In case you are interested, here is link to a web page on Structure Marking:
http://www.multicians.org/thvv/marking.html

I'm so happy you sent the tip on using the e2label to correct my problem.

I've attached my script which I wrote more out of curiosity than anything else:
ca18e1eb99c1279e0298db56f43b1ab1  genallsbs.sh

Regards,

-- Tom


From:  Theodore Tso <tytso mit edu>   [Add to Address Book]
To: Thomas Watt <tango tiac net>
Cc: Andreas Dilger <adilger clusterfs com>, ext3-users redhat com
Subject: Re: How are alternate superblocks repaired?
Date: Sep 29, 2007 9:01 AM

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

 From:  Thomas Watt <tango tiac net>   [Add to Address Book]
To: Theodore Tso <tytso mit edu>
Cc: Andreas Dilger <adilger clusterfs com>, ext3-users redhat com
Subject: Re: How are alternate superblocks repaired?
Date: Sep 29, 2007 3:29 AM

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


m:  Theodore Tso <tytso mit edu>   [Add to Address Book]
To: Thomas Watt <tango tiac net>
Cc: Andreas Dilger <adilger clusterfs com>, ext3-users redhat com
Subject: Re: How are alternate superblocks repaired?
Date: Sep 28, 2007 2:55 PM

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

Attachment: genallsbs.sh
Description: application/shellscript


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