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: <20111004040033.GM6684@thunk.org>
Date:	Tue, 4 Oct 2011 00:00:33 -0400
From:	Ted Ts'o <tytso@....edu>
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 Mon, Oct 03, 2011 at 04:55:11PM -0500, 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
> 
> first,
> 
> Warning: the fs_type huge is not defined in mke2fs.conf
> 
> (when types "big" and "huge" got added, they never got a mke2fs.conf update?)

It used to be that an undefined file system type didn't flag an error.
It now does, so we should have definitions for them in mke2fs.conf.

> reallybigfile: Not enough space to build proposed filesystem while setting up superblock
> 
> because:
> 
>         fs->group_desc_count = (blk_t) ext2fs_div64_ceil(
>                 ext2fs_blocks_count(super) - super->s_first_data_block,
>                 EXT2_BLOCKS_PER_GROUP(super));
>         if (fs->group_desc_count == 0) {
>                 retval = EXT2_ET_TOOSMALL;
> 
> The div64_ceil returns > 2^32 (2^33, actually), and the cast to blk_t
> (which should be dgrp_t?) turns that into a 0.

Yep, that should be dgrp_t.  Oops.

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

Well, we probably do want to engage bigalloc automatically, at some
point (I want to wait until bigalloc is in commonly used kernels, at
least for community distro's).  I'm not sure what the best cluster
size to pick by default should be, though.  16k?  64k?

     	     		       	   	    	  - 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