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
