Re: ext3 corruption

[Theodore Tso <tytso@mit.edu>]

On Thu, Aug 10, 2006 at 11:00:07PM +0200, Molle Bestefich wrote:
> Duane Griffin wrote:
> >> If it doesn't take into account own changes, then the -n command is
> >> unable to produce even a slightly accurate resemblence of what would
> >> happen if I did a real run.
> >
> >It takes into account some of them (such as reading data from the
> >backup superblock if it detects corruption). Others will be irrelevent
> >for further operations. Many reports will be accurate, especially
> >fatal ones. I consider that useful, YMMV.
> 
> I've attached the output of a -n run, let's get some facts on the table.
> 
> I would be very happy if someone knowledgeable would tell me something
> useful about it.
> 
> I'm especially worried about the "70058 files, 39754 blocks used (0%)"
> message at the end of the e2fsck run.

OK, so it looks like the primary block group descriptors got trashed,
and so e2fsck had to fall back to using the backup block group
descriptors.  The summary information in the backup block group
descriptors is not backed up, for speed/performance reasons.  This is
not a problem, since that information can always be regenerated
trivially from the pass 5 information.  That's what all of "free
inodes/blocks/directories count wrong" messages in your log were all
about.

The 39754 block used (0%) is just because you were using -n and the
summary information is calculated from the filesystem summary data,
not from the pass5 count information (which was thrown away since you
were running -n and thus declined to fix the results).

I can imagine accepting a patch which sets a flag if any discrepancies
found in pass 5 are not fixed, and then if the summary information is
requested, to print a warning message indicating that the summary
information may not be correct.  But no, it's not worth it to take
into account changes that -n might make if the user had said "yes".
The complexities that would entail would be huge, and in fact as it is
e2fsck -n does give a fairly accurate report of what what is wrong
with the filesystem.  Is it 100% accurate?  No, but that was never the
goal of e2fsck -n.  If you want that, then use a dm-snapshot, and run
e2fsck on the snapshot....

						- Ted