From: Theodore Ts'o <tytso@mit.edu>
To: Paul Paulson <paul.paulson@seagate.com>
Cc: fstests@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] generic/017: skip tests with mkfs failures
Date: Tue, 7 Oct 2014 22:11:02 -0400 [thread overview]
Message-ID: <20141008021102.GA20071@thunk.org> (raw)
In-Reply-To: <CAG4SSaSQt15AOOVR50EruW8sq_9Az3W26z+7pHy-2E9D3gOcgg@mail.gmail.com>
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.
Cheers,
- Ted
next prev parent reply other threads:[~2014-10-08 2:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-06 18:23 [PATCH] generic/017: skip tests with mkfs failures Paul Paulson
2014-10-06 23:21 ` Dave Chinner
2014-10-07 18:18 ` Paul Paulson
2014-10-07 0:53 ` Theodore Ts'o
2014-10-07 18:12 ` Paul Paulson
2014-10-08 2:11 ` Theodore Ts'o [this message]
2014-10-08 13:17 ` Paul Paulson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141008021102.GA20071@thunk.org \
--to=tytso@mit.edu \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=paul.paulson@seagate.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.