Christian Kujau wrote: > On Fri, 24 Apr 2009, Eric Sandeen wrote: >> Christian, is there anything in dmesg along with it this time? > > Yes, as soon as the input/output errors occur, I get: > > [34989.160273] EXT4-fs error (device md0): ext4_ext_check_inode: bad header/extent in inode #12042: invalid magic - magic 800, entries 8192, max 5696(0), depth 6144(6144) > [34989.162491] EXT4-fs error (device md0): ext4_ext_check_inode: bad header/extent in inode #12207: invalid magic - magic 42fc, entries 17104, max 62268(0), depth 1283(1283) > [34989.166784] EXT4-fs error (device md0): ext4_ext_check_inode: bad header/extent in inode #12249: invalid magic - magic 42fc, entries 17104, max 62268(0), depth 1283(1283) Oh, duh, of course. Now that I'm thinking about it right ... So these are funny inodes: # file mnt/lost+found/* mnt/lost+found/#12042: setuid setgid character special mnt/lost+found/#12207: setgid socket mnt/lost+found/#12249: setgid socket by virtue of the corruption. They don't actually have any blocks, debugfs: stat <12042> Inode: 12042 Type: character special Mode: 0012 Flags: 0xe0406 Generation: 1123828476 Version: 0x21204098 User: -62782456 Group: -62766025 Size: 0 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 0 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x00063400 -- Mon Jan 5 10:55:28 1970 atime: 0x01380030 -- Tue Aug 25 10:48:00 1970 mtime: 0x00103001 -- Tue Jan 13 00:41:05 1970 Size of extra inode fields: 4 Device major/minor number: 08:00 (hex 08:00) so we shouldn't be checking the extent header, I think. if (ei->i_flags & EXT4_EXTENTS_FL) { /* Validate extent which is part of inode */ ret = ext4_ext_check_inode(inode); } else if ... Or maybe fsck should be clearing the extents flag on inodes like this? -Eric -- 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