Re: Memory allocation failed during fsck of large EXT4 filesystem
Hi,
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614082
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
triggered.
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
trace.
There are glib functions backtrace(3) and backtrace_symbols_fd(3).
https://www.gnu.org/software/libc/manual/html_node/Backtraces.html
Their usage is shown in the handler function of
https://stackoverflow.com/questions/77005/how-to-automatically-generate-a-stacktrace-when-my-program-crashes
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 :)
Thomas
Reply to: