Hi there! I've found that on that filesystem, in many folders I now have found every 8th file has as contents instead of what it should have a copy of every other 4th file - with some aditional zeros after it. Maybe its more clear I give an example: A folder with 25 files: file 5 is a copy of 1 file 13 is a copy of 9 file 21 is a copy of 17 The original contents of file 5, 13 and 21 seem to have been lost, maybe they are in the lost+found folder. The problem doesn't always start with the first file in a folder, and doesn't always continue to the end of the folder. 2012/11/13 Theodore Ts'o <tytso@xxxxxxxxx> > > To follow up on the list since Thomas and I have had a number of > e-mail exchanges that were off-list, and he has sent me an compressed, > raw e2image dump of his file system which I have investigated > > The proximate cause of the fs corruption seems to be a few inode table > blocks written offset by a 1024 bytes --- there were 3 pairs of inodes > of the form (N, N+4) which had the exact same contents in the inode > structure (same generation number, same mtime/ctime/atimes, same > extents). This pattern of corruption is quite odd given that the file > system has a 4k block size. The best bet is that the corruption > happened at the USB device layer, since the mis-written inodes were > offset by a 2 512 byte sectors, as opposed to by an incorrect block > number. Thomas tells me this particular device has had a flaky USB > controller and this is the not the first such failure. > > There also seems to be a bug in e2fsck which caused it not to be able > to repair the corrupted file system. I have not had a chance to track > down the bug yet. It may have been caused by how we handle extent > tree blocks getting cached while trying to clone the data block. > Something which we should fix, but ultimately, the use of metadata > checksums is going to be the best way to deal with cases of the inode > table block getting written to the wrong place on disk, since we will > then know which inode not to trust, and just have e2fsck zap it. > > Speaking of zapping, I've given Thomas instructions on how to clri > three of the duplicated inodes using debugfs, and that allowed e2fsck > to be able to repair his file system. He will have suffered some data > loss due to the corrupted inode table, but at least this way he'll be > able to gain access to most of the files on the disk. > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
