Hi,
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
https://codesearch.debian.net/search?q=package%3Ae2fsprogs+Memory+allocation+failed
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.
https://sources.debian.org/src/e2fsprogs/1.46.2-2/lib/ext2fs/icount.c/?hl=461#L461
https://sources.debian.org/src/e2fsprogs/1.46.2-2/lib/ext2fs/icount.c/?hl=388#L388
(in line 496 the same return value leads to ENOENT.)
In
https://sources.debian.org/src/e2fsprogs/1.46.2-2/lib/ext2fs/hashmap.c/?hl=33#L33
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 :)
Thomas