Bug 131685
Summary: | Problem with synchronization of superblock backups | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Emmanuel Druon <emmanuel.druon> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 2 | CC: | sct |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-04 14:17:28 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Emmanuel Druon
2004-09-03 08:28:28 UTC
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? |