Policy after fsck fixes errors
tytso at mit.edu
Wed Jan 19 13:56:53 UTC 2005
On Wed, Jan 19, 2005 at 09:16:37AM +0000, Geoff wrote:
> Yesterday evening this box crashed and, for once, ext3 was
> not able to recover automatically. There was an
> "unexpected inconsistency inode xxxxx has imagic flag set"
> error and the system would not boot. I fscked from my
> rescue disk and I guess 20 or 30 errors were fixed by me
> just selecting "y" at the prompt.
Did you save all of the other fsck messages? Was there any messages
about directory entries to deleted files being deleted, or files
ending up in lost+found?
This sounds like garbage was written into your inode table; depending
on where the garbage was written, yes there could have been files that
ended up going missing as a result.
> The system then booted and, so far as I can tell, the only
> problem was that my firefox profile was corrupt (I have a
> feeling that an old configuration got restored instead of
> the current one). That was easily fixed, but I am left
> wondering whether there might not be other, less
> immediately detectable, problems remaining which could show
> up later. Since fixing the profile I have forced another
> fsck which (as you would expect I suppose), does not throw
> up any errors.
Right, there would be no further filesystem corruption (unless
whatever caused garbage to appear in the first place --- bad
controller, bad IDE/SCSI cable, failing hard drive, etc. --- is still
causing additional damage to the filesystem).
However, files might be missing.
It might be worthwhile to compare the files on your backup hdd with
your current filesystem, to see if you have any missing files. It's
also possible I suppose that data blocks were actually corrupted, but
that really depends on how the inode table blocks got corrupted in the
> (b) Are there any other diagnostics I could run to confirm
> the integrity of my data?
Aside from comparisons to backups, if you had been using programs like
cfv to calculate checksums of all of your files, you could use them to
check the data integrity of your data files.
On rpm-based systems, you can also do things like rpm -Va to check the
checksums of the installed files. This won't check your data files,
and will raise false positives caused by config files that you have
since modified, but it might give you a hint that there is greater
damage, or put your mind at ease that things are more likely to be OK.
More information about the Ext3-users