On Apr 08, 2009 09:09 +0930, Kevin Shanahan wrote: > On Tue, Apr 07, 2009 at 04:13:24PM -0700, Andreas Dilger wrote: > > What version of e2fsprogs is this? It definitely appears that the > > inode is corrupted (bad i_file_acl field), and e2fsck isn't fixing it. > > Using current Debian stable release: > > hermes:~# e2fsck -V > e2fsck 1.41.3 (12-Oct-2008) > Using EXT2FS Library version 1.41.3, 12-Oct-2008 > > > Can you please dump this inode using "debugfs -c -R 'imap 383' /dev/dm-0" > > and "dd if=/dev/dm-0 of=/tmp/bad_inode.383.bin bs=4k count=1 skip={blocknr}". > > hermes:~# debugfs -c -R 'imap 383' /dev/dm-0 > debugfs 1.41.3 (12-Oct-2008) > /dev/dm-0: catastrophic mode - not reading inode or group bitmaps > 383: File not found by ext2_lookup > hermes:~# debugfs -c -R 'imap <383>' /dev/dm-0 > debugfs 1.41.3 (12-Oct-2008) > /dev/dm-0: catastrophic mode - not reading inode or group bitmaps > Inode 383 is part of block group 0 > located at block 312, offset 0x0e00 000e00 845ac901 00000000 5d648154 9f6a0b23 000e10 22344c51 00000000 0001e064 00000000 000e20 c4a8c000 c591d204 9105f87d c6cf35c8 000e30 82016f23 d3a7defb af4ab245 d3123ef4 000e40 87cd5ebe fa60d394 db745504 a6f3a34d 000e50 6a5985d4 ac8cebf1 a605db29 548c8e6e 000e60 f665b0c8 e58c1934 00000000 00000000 000e70 00000000 5db50000 b6ae09f5 6bc9469f 000e80 9c950004 5b8f755b e31b8760 e49bfe80 000e90 215242b0 f708f501 ab1d808d 4143a941 000ea0 83ff4c83 36858a3e db376e67 c87ee64e 000eb0 c10e0487 8dc325a1 4e7327aa 71a6c841 000ec0 4014140b d18816c7 87898dba b986e891 000ed0 2dab53ed 8fef04ef f33deb1c 47010862 000ee0 c551c546 2c463176 0b0c554a 76af3850 000ef0 271cc4fa 457664de 79b808d5 4456415a This inode looks like total garbage, unlike the ones immediately before and after it in the same block. Why e2fsck doesn't complain about this inode is a bit of a mystery. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- 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