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 _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
