On Tue, 2009-03-10 at 10:46 -0400, Theodore Tso wrote: > > > hermes:~# debugfs /dev/dm-0 > > > debugfs 1.41.3 (12-Oct-2008) > > > debugfs: stat "local/apps/Gestalt.Net/SetupCD/program files/Business Objects/Common/3.5/bin/Cdo32sv.dll" > > > > > > Gives the following output: > > > > > > Inode: 867 Type: bad type Mode: 0404 Flags: 0x802a61af > > > Generation: 2483046020 Version: 0xb9286359:17a7fdfd > > > User: 1455931783 Group: -798021131 Size: -1808719531 > > > File ACL: 141934744 Directory ACL: 0 > > > Links: 15681 Blockcount: 171984001880781 > > > Fragment: Address: 956780679 Number: 0 Size: 0 > > > ctime: 0xdca60244:006c5b08 -- Wed Apr 23 01:54:36 2087 > > > atime: 0x5c9e956c:777587a4 -- Sat Mar 30 08:30:12 2019 > > > mtime: 0x2ce44e11:286138f8 -- Sat Nov 13 13:31:37 1993 > > > crtime: 0x737781cb:5661f351 -- Thu May 22 19:54:11 2031 > > > dtime: 0xf19c4882 -- Sat Jun 14 11:57:14 2098 > > > Size of extra inode fields: 3625 > > > BLOCKS: > > This looks like a block written to the wrong place on disk. One of > the things that can be done is to dump out the disk block > corresponding to inode #867 before the fsck, and see if we can > recognize what the source of the block was. Thanks Ted. Just so I know what I'm doing if/when this comes up again, I guess the process would be: - debugfs /dev/some-filesystem - debugfs: stat "some/problem/file" - get the inode number from the output above (867 in this case) - debugfs dump 867 inode867.bin Or perhaps running e2fsck -n first to see which inodes really look corrupted and get the numbers that way. > Failures like this have been reported on ext3 filesystems as well, but > it's rare, and it's been written off to hardware failure, although it > could be really anything --- from the device driver, block layer, a > filesystem problem, or hardware hiccup. > > Given that you've fixed it, all I think we can tell you is to keep an > eye out for any further failures.... Thanks, will do. Cheers, Kevin. -- 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
