Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #236910

Re: Memory allocation failed during fsck of large EXT4 filesystem

From Reiner Buehl <reiner.buehl@gmail.com>
Newsgroups linux.debian.user
Subject Re: Memory allocation failed during fsck of large EXT4 filesystem
Date 2021-07-05 16:20 +0200
Message-ID <CxxC1-q2-9@gated-at.bofh.it> (permalink)
References <Cxs9j-5fv-1@gated-at.bofh.it> <Cxtyq-61a-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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
>:

> 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
>
>

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Memory allocation failed during fsck of large EXT4 filesystem Reiner Buehl <reiner.buehl@gmail.com> - 2021-07-05 10:30 +0200
  Re: Memory allocation failed during fsck of large EXT4 filesystem IL Ka <kazakevichilya@gmail.com> - 2021-07-05 11:50 +0200
    Re: Memory allocation failed during fsck of large EXT4 filesystem Michael Stone <mstone@debian.org> - 2021-07-05 23:00 +0200
      Re: Memory allocation failed during fsck of large EXT4 filesystem "Thomas D. Dean" <tomdean@wavecable.com> - 2021-07-05 23:30 +0200
        Re: Memory allocation failed during fsck of large EXT4 filesystem Michael Stone <mstone@debian.org> - 2021-07-05 23:30 +0200
        Re: Memory allocation failed during fsck of large EXT4 filesystem Reiner Buehl <reiner.buehl@gmail.com> - 2021-07-06 09:20 +0200
          Re: Memory allocation failed during fsck of large EXT4 filesystem "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-06 13:30 +0200
  Re: Memory allocation failed during fsck of large EXT4 filesystem "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-05 12:00 +0200
    Re: Memory allocation failed during fsck of large EXT4 filesystem Reiner Buehl <reiner.buehl@gmail.com> - 2021-07-05 16:20 +0200
      Re: Memory allocation failed during fsck of large EXT4 filesystem IL Ka <kazakevichilya@gmail.com> - 2021-07-05 16:40 +0200
        Re: Memory allocation failed during fsck of large EXT4 filesystem IL Ka <kazakevichilya@gmail.com> - 2021-07-06 13:40 +0200
          Re: Memory allocation failed during fsck of large EXT4 filesystem Andy Smith <andy@strugglers.net> - 2021-07-06 15:20 +0200
  Re: Memory allocation failed during fsck of large EXT4 filesystem Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-05 17:20 +0200
  Re: Memory allocation failed during fsck of large EXT4 filesystem Marc Auslander <marcausl@gmail.com> - 2021-07-05 18:40 +0200

csiph-web