Linux – e2fsck – out of memory despite [scratch_files] set in /etc/e2fsck.conf

fscklinuxmemory

I'd like to repair an ext2 file system on an external 16GB SD card drive.

When I issue the following command:

e2fsck -y /dev/xxx

my system runs out of memory (Fedora 17 x64 8GB RAM, 8GB Swap).

As suggested elsewhere, I've added:

[scratch_files]
directory = /var/cache/e2fsck    # (this directory exists and is writable to all)

to:

/etc/e2fsck.conf

Unfortunately, this fix does not seem to work. e2fsck does use the /var/cache/e2fsck directory, but still runs out of memory.

When I run the command interactively, it stops at the following prompt:

Inode 758 has an invalid extent
    (logical block 0, invalid physical block 140737488469058, len 1)
Clear<y>? yes
Inode 758, i_blocks is 8, should be 0.  Fix<y>?

Answering yes or no to that prompt has the same result: the RAM used by e2fsck jumps suddenly to 8GB+ and my system freezes.

EDIT : Within VirtualBox

I tried fsck within VirtualBox, with a whopping 40Gb swap space. Fsck used all the 4GB RAM and about 30 GB swap, then it died with the following error message:

Error storing directory block information (inode=759, block=0, num=295645313): 
Memory allocation failed

Best Answer

A memory jump sounds like an e2fsck bug. If that is the case the problem may be solved by caring about this inode manually (with debugfs; I am not familiar enough though to explain how to do that).

If it's not a bug and e2fsck just needs more memory then there is a "solution" which does not require adding RAM but it would certainly "redefine performance"... The problem is that e2fsck does not use swap memory as equivalent. At least that was the situation in a similar case. Does your swap space get filled completely before e2fsck crashes? Probably not.

You can trick e2fsck into accepting swap as real RAM: You can boot a second Linux in a VM and export the block device to be checked to the VM. You configure the VM with more memory than physically available. e2fsck in the VM will see more RAM. Of course, this does not make the use of scratch_files unnecessary.

I had problems starting a VM with more memory allocation than there was physical(!) RAM available but according to the Fedora docs this is supposed to be possible (maybe that was not even a KVM/QEMU problem but some fancy kernel stuff).

Related Topic