Bug 131685 - Problem with synchronization of superblock backups
Problem with synchronization of superblock backups
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
2
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-03 04:28 EDT by Emmanuel Druon
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-04 10:17:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Emmanuel Druon 2004-09-03 04:28:28 EDT
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
Comment 1 Josh Bressers 2004-09-03 16:25:33 EDT
Removing the security severity, this is a bug, not a security issue.
Comment 2 Emmanuel Druon 2004-09-04 11:04:24 EDT
Sorry Josh, but as far as I'm concerned it's a (data) security issue
;-) but I accept it as a "bug" anyway"
Comment 3 Thomas Woerner 2004-10-04 09:56:07 EDT
Assigning to kernel. Superblock backups are handled by the filesystem
itself.
Comment 4 Stephen Tweedie 2004-10-04 10:17:28 EDT
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.
Comment 5 Emmanuel Druon 2004-10-04 10:30:19 EDT
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.

Comment 6 Stephen Tweedie 2004-10-04 12:30:42 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.