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 <scdbac...@gmx.net >: > 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 > >
