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] [day] [month] [year] [list]

Message-ID: <CAG4SSaTFcfM8KkyJbiCed6URHa3YcMWc84+3toLA12q_V_QtDg@mail.gmail.com>
Date:	Wed, 8 Oct 2014 08:17:41 -0500
From:	Paul Paulson <paul.paulson@...gate.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	fstests <fstests@...r.kernel.org>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] generic/017: skip tests with mkfs failures

On Tue, Oct 7, 2014 at 9:11 PM, Theodore Ts'o <tytso@....edu> wrote:
> On Tue, Oct 07, 2014 at 01:12:51PM -0500, Paul Paulson wrote:
>> 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).
>
> Sure, but the default file system configs don't include 1k block
> sizes.  There really is only one reason that I care about the 1k block
> size --- it's to make it easy to validate on an x86 architecture what
> happens when a file system with a default 4k block size is mounted on
> an architectures such as PowerPC or Itanium which has a page size of
> 16k or 64k.  That is, to test the case where block size < page size.
>
> But we really don't encourage people use a 1k block size in
> production.  And while it would make sense from a performance point of
> view to use a 16k or 64k block size file system on a PowerPC or
> Itanium system, people who care about making their file system
> portable across PowerPC and x86 (for example) will need to use a 4k
> block file system (since Linux doesn't support block size > page
> size).
>
> So using a 1k block file system on a terabyte file system is neither
> the default nor a sane thing to do.  I'll look into making mke2fs
> handle this case more smoothly, but it's not something that I consider
> a high priority or something I would encourage as a realstic
> production use case.

Thank you for your informative explanation. It sounds like Dave will
bring in the patch to eliminate the multiple block size loop so we'll
just wait for that.
--
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