How are alternate superblocks repaired?

Thomas Watt tango at
Thu Sep 27 14:39:28 UTC 2007

Hi Andreas,

Thank you for replying.

I have written a metascript which generates a shell script to dump all of the superblock information you have requested, however, only the primary and first backup are compared and then the first backup is compared with the remaining bad backup superblocks.  That's not exactly what you requested, but will it suffice?  If not, I can easily fix it to make the comparisons using the primary (good) superblock as the anchor instead of the (bad) first backup superblock.  Outputs are: text, binary, and xxd hex dump formats with separate subdirectories and comparison scripts.  I have noticed that a lack of textual difference in broken superblocks does not correlate in binary difference - i.e. they are different.

I understand that there was a previous kernel bug in the mount command regarding the -o sync option, and that it has been fixed in a subsequent release.  Consequently, I am for the moment not using that option on mounting the FC3 disk.  In what version of the kernel was the fix for the mount command -o sync bug?

I suppose I still have a question that if the online resizing code is the only other code to touch the backup superblocks (out of necessity), then what is the recommended frequency on running e2fsck with what parameters to insure that the backup superblocks remain in good, usable condition?  Should this be done within FC3 natively in single user mode or will a Live CD environment with a newer version of e2fsck be more appropriate?


-- Tom

On Sep 20, 2007  17:36 -0400, Thomas Watt wrote:
> Using dumpe2fs I have been able to determine that all of my alternate
> ext3 superblocks are corrupted (not clean), and only the primary
> superblock is valid, i.e. mount works and the ordered journal is applied.
> When the primary superblock gets flakey, i.e. the ext_attr Filesystem
> feature goes missing - not sure why this occurs.  At this point, the
> mount does not apply the journal using the primary superblock and mount
> completes without it.  Usually, I will resort to booting up the FC3
> OS hard drive on which the ext3 filesystem resides to fix at least the
> primary superblock via fsck.

Normally the superblock backups are touched only when e2fsck runs.  This
ensures that the backups are not touched by the kernel and not also "updated"
with corruption in case of a software/hardware problem.

The only code I know that updates the backup superblocks is the online
resizing code, because if it doesn't the backup copies will no longer be
useful (i.e. any data written beyond the old end-of-filesystem would be

> Will the command: e2fsck -fp /dev/sdb2 repair the alternate superblocks,
> and if so, should it only be run from the Live CD environment?  Or,
> do I need to get into runlevel 1 as single user to issue the command
> after unmounting the hard drive in order to run it?

The e2fsck should handle it.  Can you post the differences between the
bad and good superblocks before you do so?

Cheers, Andreas
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

More information about the Ext3-users mailing list