On Mar 10, 2009 22:45 +1030, Kevin Shanahan wrote: > hermes:~# e2fsck -pfv /dev/dm-0 > /dev/dm-0: Inode 865 is in use, but has dtime set. FIXED. > /dev/dm-0: Inode 865 has a extra size (33096) which is invalid > FIXED. > /dev/dm-0: Inode 865 has INDEX_FL flag set but is not a directory. > HTREE INDEX CLEARED. > /dev/dm-0: Inode 865, i_size is 11708523728200260508, should be 0. FIXED. > /dev/dm-0: Inode 865, i_blocks is 3851901040, should be 0. FIXED. These all mean the inode is garbage. The Lustre e2fsprogs has a patch "e2fsprogs-badness_counter" that tracks the number of errors hit in the inode, and clears it if it appears to be garbage (as in your case), instead of turning a pile of manure into neatly organized fertilizer. > Pass 2: Checking directory structure > Inode 867 (/local/apps/Gestalt.Net/SetupCD/program files/Business Objects/Common/3.5/bin/Cdo32sv.dll) has invalid mode (0152404). > Clear<y>? yes This is just more indication of the inodes being corrupted. > Pass 3: Checking directory connectivity > Pass 3A: Optimizing directories > Error reading block 2705859237 (Invalid argument). Ignore error<y>? yes > > Force rewrite<y>? yes > > Error writing block 2705859237 (Invalid argument). Ignore error<y>? yes Hmm, is this read beyond EOF? The block pointers should be fixed by this time, so there may be a hole in e2fsck at this point. I assume you do not have a 10TB filesystem here. 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
