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

Re: Memory allocation failed during fsck of large EXT4 filesystem

It seems swap is not the solution: Even after adding a 50G swap file, I still get the same error message and the swap usage stats from collectd show that max swap usage was not more than just 2G.

I will now try if the scratch_files stanza makes a difference.

Am Mo., 5. Juli 2021 um 11:50 Uhr schrieb Thomas Schmitt <scdbackup@gmx.net>:

Reiner Buehl wrote:
> Is there a quick way to enlarge the swap space

According to old memories of mine you may create a large, non-sparse file
as you would do for a virtual disk. E.g. by mkfile (which seems not to be
in Debian) or qemu-img (from qemu-utils):

  qemu-img create "$swap_file_path" 8G

Set ownership and access rights of "$swap_file_path" so that no
unprivileged users can spy.

Then you tell the system to use it for swapping

  swapon "$swap_file_path"

> fsck.ext4 fails with the error message:
> Error storing directory block information (inode=366740508, block=0,
> num=406081): Memory allocation failed

According to
this message is emitted if error code EXT2_ET_NO_MEMORY was returned.
This error code indeed occurs if memory allocating system calls fail.
In these cases i would expect that more virtual memory could help.


But i see questionable occurences of EXT2_ET_NO_MEMORY which get triggered
by bad data. In these cases no extra memory can help:

Halfways correct is its use to mark an insane request for a memory array
which would exceed the maximum number that can be stored in unsigned long
integer variables.

There are possible misattributions of that error code if get_icount_el()
returns 0 to set_inode_count() for reasons of bad data.
(in line 496 the same return value leads to ENOENT.)

i see a potential memory fault by using the calloc(3) return without
checking it for NULL. (A caller of ext2fs_hashmap_create() would later
throw EXT2_ET_NO_MEMORY if the program did not crash yet.)

Return value 0 from get_refcount_el() is converted to EXT2_ET_NO_MEMORY
in ea_refcount_increment(), although get_refcount_el() did not attempt to
allocate memory.

It stays a riddle from where e2fsprogs links sparse_file_new(). I find it
only as Android C++ call. Whatever, if it fails then EXT2_ET_NO_MEMORY
can be returned by its caller io_manager_configure(), which seems not
restricted to Android.

Have a nice day :)


Reply to: