linux-ext4 - Re: mkfs'ing a 48-bit fs... or not.

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: <4E8A859C.2070501@redhat.com>
Date:	Mon, 03 Oct 2011 23:03:40 -0500
From:	Eric Sandeen <sandeen@...hat.com>
To:	Eric Sandeen <sandeen@...deen.net>
CC:	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: mkfs'ing a 48-bit fs... or not.

On 10/3/11 4:55 PM, Eric Sandeen wrote:
> Has anyone tried mke2fs at its limits?  The latest git tree seems to fail in several ways.
> (Richard Jones reported the initial failure)
> 
> # truncate --size 1152921504606846976 reallybigfile 
> # mke2fs -t ext4 reallybigfile

...

> Trying it with "-O bigalloc" (which should be automatic at this size,
> I think?) just goes away for a very long time, I'm not sure what it's
> thinking about, or if it's in a loop somewhere (looking now).

It comes up with too many inodes, then tries to reduce the count,
but the "waste not want not" logic bumps it back up... ipg eventually
goes "below" 0 but it's unsigned so it goes on in this loop forever.

Some of this is my fault... I put that retry logic in years ago.  :(

I'll see what I can do to fix it up.

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