On Mon, Mar 31, 2014 at 03:49:29PM -0500, Justin Brown wrote: > Pass 1: Checking inodes, blocks, and sizes > Inode 14109880 has illegal block(s). Clear? yes > > Illegal block #0 (3925875673) in inode 14109880. CLEARED. > Illegal block #2 (85326080) in inode 14109880. CLEARED. > Illegal block #3 (2516589529) in inode 14109880. CLEARED. > Illegal block #5 (3641317099) in inode 14109880. CLEARED. > Illegal block #6 (394723355) in inode 14109880. CLEARED. > Illegal block #7 (2986344453) in inode 14109880. CLEARED. > Illegal block #8 (3640903191) in inode 14109880. CLEARED. > Illegal block #9 (463536155) in inode 14109880. CLEARED. > Illegal block #11 (1275199487) in inode 14109880. CLEARED. > Illegal double indirect block (2181366192) in inode 14109880. CLEARED. > Illegal block #563086348 (4294967295) in inode 14109880. CLEARED. > Error storing directory block information (inode=14109880, block=0, > num=471166008): Memory allocation failed Sorry, this is a bug in e2fsck; we should handle this kind of corrupted inode better. The quick workaround is this: debugfs -w -R "clri <14109880>" /dev/vg/root This will zap the contents of the offending inode, since it's been overwritten with garbage; unfortunately, it was garbage which was causing e2fsck to try to allocate too much memory, and then fail. - 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
