Red Hat Bugzilla – Bug 131685
Problem with synchronization of superblock backups
Last modified: 2007-11-30 17:10:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
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
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
Is there a way to resynchronize the backups with the "master" ?
Version-Release number of selected component (if applicable):
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
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
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?