linux-ext4 - Re: Fsck.ext4: Memory Allocation Failed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKZK7uwC=M0F6dtYZXjo6dd9yh=0PObsg5BYvP=UjyN0Pr5H-A@mail.gmail.com>
Date:	Tue, 1 Apr 2014 15:15:54 -0500
From:	Justin Brown <justin.brown@...dingo.org>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Fsck.ext4: Memory Allocation Failed

Hi Ted,

Thanks for the reply. I had to repeat that on a couple other blocks,
but it seems to work.

I do have one other question. The fsck has been running for several
hours now, and while it was fixing lots of errors at the beginning,
there hasn't been any output from fsck in ~2 hours. I assume that it's
still on stage 1 block and inode check. There are two interesting
things. First, memory utilization is 9GiB (not including cache) and
has been stable for a long time now, which seems quite odd that memory
utilization has remained so high. Second, I attached strace to the
fsck process. It's not particularly easy for me to tell what's
happening, but it seems like fsck is going through every inode doing a
4096 write, lseek -4096, read 4096, and then lseek off to some other
place. I'm surprised that fsck would be doing such a large number of
writes, especially given that there's no new messages on
stdout/stderr. It's more like behavior that I would expect from
defragmentation. Does this seem normal?

Cheers,
Justin

On Mon, Mar 31, 2014 at 9:22 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Mon, Mar 31, 2014 at 03:49:29PM -0500, Justin Brown wrote:
>> Pass 1: Checking inodes, blocks, and sizes
>> Inode 14109880 has illegal block(s).  Clear? yes
>>
>> Illegal block #0 (3925875673) in inode 14109880.  CLEARED.
>> Illegal block #2 (85326080) in inode 14109880.  CLEARED.
>> Illegal block #3 (2516589529) in inode 14109880.  CLEARED.
>> Illegal block #5 (3641317099) in inode 14109880.  CLEARED.
>> Illegal block #6 (394723355) in inode 14109880.  CLEARED.
>> Illegal block #7 (2986344453) in inode 14109880.  CLEARED.
>> Illegal block #8 (3640903191) in inode 14109880.  CLEARED.
>> Illegal block #9 (463536155) in inode 14109880.  CLEARED.
>> Illegal block #11 (1275199487) in inode 14109880.  CLEARED.
>> Illegal double indirect block (2181366192) in inode 14109880.  CLEARED.
>> Illegal block #563086348 (4294967295) in inode 14109880.  CLEARED.
>> Error storing directory block information (inode=14109880, block=0,
>> num=471166008): Memory allocation failed
>
> Sorry, this is a bug in e2fsck; we should handle this kind of
> corrupted inode better.
>
> The quick workaround is this:
>
> debugfs -w -R "clri <14109880>" /dev/vg/root
>
> This will zap the contents of the offending inode, since it's been
> overwritten with garbage; unfortunately, it was garbage which was
> causing e2fsck to try to allocate too much memory, and then fail.
>
>                                       - Ted
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html