linux-ext4 - Re: [PATCH] generic/017: skip tests with mkfs failures

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]

Date:	Tue, 7 Oct 2014 13:12:51 -0500
From:	Paul Paulson <paul.paulson@...gate.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	fstests@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] generic/017: skip tests with mkfs failures

On Mon, Oct 6, 2014 at 7:53 PM, Theodore Ts'o <tytso@....edu> wrote:
>
> On Mon, Oct 06, 2014 at 01:23:50PM -0500, Paul Paulson wrote:
> > The mkfs command fails to create ext4 filesystems on partition sizes
> > greater than 1998080 MiB when using 1024 byte blocks and the default
> > calculation for the number of inodes reserved for the filesystem.
>
> I've never noticed a problem because creating a partition that large
> makes the xfstests runs take a long, long time.  I typically use a 5
> GB or 20GB partition.  Is there a particular reason why you are trying
> to do test ext4 using a 1k blocksize for a 2T file system?  We can fix
> mke2fs so it doesn't fail when you create a > 2T file system with a 1k
> block size, but the bigger question in my mind is why anyone would
> ever want to do that?
>
>                                         - Ted
We'd like to run the full test suite using maximum partition sizes on
SMR drives for functional and performance evaluation purposes. Since
drive capacities are increasing so rapidly it would be nice if mke2fs
would support filesystems up to the maximum configurations specified
in the Ext4_Disk_Layout document using default filesystem configs. For
example, the 127877120 inode limit that we ran into is only 3% of the
number of inodes specified in the document (2^32 inodes in a 4 TiB
filesystem with 1KiB block sizes for 32-bit mode).
--
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