Hm, I wish you could have grabbed the output of dumpe2fs on the
parition before you ran the old e2fsck. That would have been very
helpful indeed.
The change in question is this one:
commit 009c02baf90a55b4b2d9c9e3d0a4cfc3e2531640
Author: Theodore Ts'o <ty...@mit.edu>
Date: Thu Jul 10 16:35:05 2008 -0400
Make ext2fs_check_desc() more stringent to force use of backup superbocks
E2fsck could to do more damage to a filesystem by trying to relocate
inode tables due to corrupted block group descriptors, and the
relocation could seriously damage the filesystem.
This patch enhances ext2fs_check_desk() so it detects more
self-inconsistent block group descriptors, including the cases where
e2sck might be tempted to relocate the inode table, and reports the
block group descriptors as invalid; this will cause e2fsck to attempt
to use the backup superblocks, which hopefully have not been trashed.
Addresses-Sourceforge-Bug: #1840291
Signed-off-by: "Theodore Ts'o" <ty...@mit.edu>
And yes, it was intentional that it did what it did; basically, you
got lucky because the older e2fsck could have seriously screwed up
your filesystem to the point where seriously data loss could have
occurred (you do keep regular backus, right?).
What puzzles me is how come you got as far as you did with the first
(boot-time) fsck:
> During a routine filesystem check at boot, e2fsck discovered the following:
>
> # /dev/vg2/backuppc has gone 264 days without being checked,
> # check forced.
> # /dev/vg2/backuppc: Group 15625's block bitmap at 512001023 conflicts
> # with some other fs block.
> # /dev/vg2/backuppc: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> # (i.e., without -a or -p options)
The corruption reported when you ran fsck manually, to wit:
> # e2fsck 1.41.3 (12-Oct-2008)
> # e2fsck: Group descriptors look bad... trying backup blocks...
> # e2fsck: Bad magic number in super-block while trying to open
> # /dev/vg2/backuppc
Should have shown up at the boot-time fsck, unless somehow the
filesystem was further corrupted after (or during) the initial
boot-time fsck run.
Worse yet, whatever corruption you had apparently had spread to your
backup blocks, which is also very wrong. E2fsck is only supported to
write to the master superblock only until it is sure everything is
consistent. I'll have to try to play around with some test
filesystems to see if I can reproduce what you saw.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
