Re: unusual ext2 FS corruption -- for statistics

Theodore Y. Ts'o (tytso@mit.edu)
Fri, 23 Jul 1999 13:44:41 -0400


Date: Fri, 23 Jul 1999 13:51:45 +0200
From: Frank van Maarseveen <fvm@tasking.nl>

I think that 2.2.6-ac3 or one of the drivers was responsible for some
FS corruption. A shutdown couldn't unmount the file systems. On the next
boot Fsck detected this and filled /lost+found with strange looking files
(actually bogus block special devices). After getting rid of all of
this a disk fingerprinting tool discovered unusual modes on some files
(not seen as incorrect by e2fsprogs-1.10-6 or e2fsprogs-1.15-0):

It's very interesting that e2fsprogs 1.15 (or e2fsprogs 1.14) didn't
consider the inodes to be invalid. The hueristic used is that for block
or character devices, if the direct blocks beyond the fourth are
non-zero, the inode is considered garbage. Given random data written
into the inode table, the chance of garbage being recognized as a
correct inode are rather high. One in 2**232, to be precise. (Eleven
words times 32 bits/word == 232, and all 232 bits have to be zero for it
to be mistaken as a correct inode.)

Obviously, though, not all corruptions are random. But the fact that
you're seeing more than one of these bogus inodes seems to indicate
something truely funny going on. Somehow the corruption is happening in
such a way as to fool newer (1.14 and 1.15) e2fsprogs's hueristics.

This might be a useful hint to determining from where the corruption
originating. I first thought the corruption might be happening in the
in-memory copy of the inode, but the pattern of corruption doesn't seem
to bear out that that theory. The funny thing though is that the
surrounding inodes seem to be untouched, so it doesn't look like the
standard oops-we-wrote-a-data-block-into-the-wrong-place problem.

Frank, can you send some other examples of the bogus inodes you found?
The one that you sent seemed extremely unusual, and it would be
worthwhile to track down the rest to see if we can establish any pattern
as to what's going on here. Thanks!!

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/