From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 Description of problem: After installing a fresh Fedora Core 2, I noticed that they are pages and pages of inconsistencies if I'm using one of the superblock backups in fsck.ext3 instead on the master one. Reading the changes in the implementation of e2fsck, I noticed that updates of the backups seem to be now only done when major changes occured. In that case, there seem to be major differences because if I try to repare my filesystem using one of the backups, many files seem to be broken. Is there a way to resynchronize the backups with the "master" ? Version-Release number of selected component (if applicable): e2fsprogs-1.32-6 How reproducible: Sometimes Steps to Reproduce: 1. Install a fresh FC2 2. check the filesystem using a backup superblock 3. try to force a fsck.ext3 Actual Results: There seems to be a lot of desynchronization between Group0 superblocks and backups Expected Results: After an fsck.ext3 on the partition, superblock backups should be synchronized Additional info: Things are worse when you try a kickstart install for some reason
Removing the security severity, this is a bug, not a security issue.
Sorry Josh, but as far as I'm concerned it's a (data) security issue ;-) but I accept it as a "bug" anyway"
Assigning to kernel. Superblock backups are handled by the filesystem itself.
This behaviour is intended. Large filesystems can have many backups (although the number is limited if you build the fs with sparse superblocks, which is the default these days.) Updating them all synchronously would be an unacceptable performance penalty. It would also defeat part of the purpose of the backups: if something goes wrong, the backups should remain pristine so that they can be relied on during the fsck. Now, some things in the backups will go out of date. That includes the fs-wide and per-group free block / free inode counts, the last-mounted-on timestamps and so on. If you fsck from the backup, then some minor inconsistencies are expected, especially regarding the per-block-group counts. But these counts can be completely recomputed by reading the filesystem bitmaps. But if you're claiming "many files seem to be broken", that would imply there's actual *file* damage, not just bitmap count damage, that is dependent on the precise superblock in use. That's not expected (unless the superblock or backups are physically damaged in some way so that the static data in them is out of sync); if you can reproduce it, could you please attach a log showing the problem? Otherwise, it's just running as designed.
I'll try to get time to reproduce the bug but as far as I can see it, it really appears to be a bug. I understand the "small" out of synchronization issues as you stated them and it fits what I found out myself. However, when I say "broken", it meens that as far as I don't do a fsck with a superblock backup, things are ok (and I can use my computer as usual) but when I restart the computer after an fsck, I end up with kernel panic issues because some files can't be found (typically the init file but it can be others). I'll try to reproduce the bug and send you some logs about the problem but since it involves reinstalling a computer from scratch, it can take some time.
FC2 shipped with e2fsprogs-1.35-7.1. Where did the 1.32-6 version come from? Or was this a beta you were using?