Messages in this thread | | | Date | Fri, 23 Jul 1999 13:44:41 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: unusual ext2 FS corruption -- for statistics |
| |
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/
| |