retitle 614082 e2fsck dies with an OOM on bad triple-indirect block in a dir
inode
thanks
On Sat, Feb 19, 2011 at 06:09:38PM +0300, George Shuklin wrote:
> Error storing directory block information (inode=169246423, block=0,
> num=3966024): Memory allocation failed
Apologies for not looking at this sooner. I had assumed this was the
standard "user was trying to check a too-big file system with an
32-bit userspace" problem, and then I got busy and it dropped off the
end of my inbox.
In fact it's a much more interesting problem. What happened was that
you got unlucky and trash got written into your inode table. One of
the inodes that got overwritten had the directory bit set, and the
extents flag was _not_ set. So the i_blocks field was interpreted as
a series of blocks. Many of those i_blocks entries were garbage, and
were cleared, but the triple indirect block could be interpreted as a
valid block number, so we started iterating over all of the double
indirection blocks. To make sure that the directory doesn't have
"holes" in it, e2fsck then started allocating entries to keep track of
all of this via ext2fs_add_dir_block2(), and this is what caused the
memory overflow.
To fix this what we need to do is to notice when an inode looks
insane, and ask the user if they are willing to just nuke it, as
opposed to trying to fix all of the individual things that are wrong
with it.
The way to work around this problem should it occur again is to note
the inode number, and then zap it using debugfs:
debugfs -w /dev/md1
debugfs: clri <169246423>
debugfs: quit
Then e2fsck should be able to complete its work.
- Ted
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
