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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ