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
