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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 7, 2014 at 9:11 PM, Theodore Ts'o <tytso@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux