[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Memory allocation failed during fsck of large EXT4 filesystem


Reiner Buehl wrote.
> I would like to fix the filesystem
> so that I can then use more intelligent recovery methods that do not need to
> copy every file.

Maybe the old workaround proposed by Ted T'so in
would be worth a try.

Bug reporter:

  "Error storing directory block information
   (inode=169246423, block=0, num=3966024): Memory allocation failed"

Ted T'so:

  "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."

If possible i would make any experiments on a plain copy of the filesystem.
I.e. a copy of the bytes which can be read from the partition device.

Far fetched approach:

If this would not help and i would deem it worth the effort, then i'd get
the newest source of e2fsprogs and try to build it. Then i'd run the new
fsck.ext4 program on a copy of the filesystem. If it still fails with
"Memory allocation failed" then i'd try to let the program print a message
from any occasion of EXT2_ET_NO_MEMORY, describing which occasion was

This point in the source and, if possible, a stack trace would be hands-on
information for the developers of e2fsprogs.

I'm not sure how good an idea it is to run fsck under gdb to get a stack
There are glib functions backtrace(3) and backtrace_symbols_fd(3).
Their usage is shown in the handler function of
In your case no signal would be received, of course. You'd call the trace
printer from the various EXT2_ET_NO_MEMORY occasions.

As said: far fetched and open ended ...

Have a nice day :)


Reply to: