From: "Theodore Ts'o" <tytso@mit.edu>
To: Eryu Guan <guaneryu@gmail.com>
Cc: Gabriel Krisman Bertazi <krisman@collabora.com>,
fstests@vger.kernel.org, linux-ext4@vger.kernel.org,
"Lakshmipathi.G" <lakshmipathi.ganapathi@collabora.co.uk>
Subject: Removing the shared class of tests
Date: Thu, 20 Jun 2019 12:21:16 -0400 [thread overview]
Message-ID: <20190620162116.GA4650@mit.edu> (raw)
In-Reply-To: <20190620112903.GF15846@desktop>
On Thu, Jun 20, 2019 at 07:29:03PM +0800, Eryu Guan wrote:
>
> IMO, shared tests are generic tests that don't have proper _require
> rules, so they're hard-coded with explicit "_supported_fs xxx yyy". With
> proper _require rules, there should be no shared tests at all, and we'd
> try avoid adding new shared tests if possible.
Thanks for the clarification, that makes sense!
I can see some shared tests that we can probably move out, actually.
shared/00[134] and shared/272 make no sense at all for ext2. The ext3
file system was removed in 2015, in the 4.3 kernel, and since 2009
(ten years ago) in 2.6.33, the ext4 implementation could be used to
support ext3 (and I believe many if not all enterprise distros been
taking advantage of this long before 2015, so they only had to update
patches for ext4).
(If anything, we might be better served by a two line patch to check
so that simply included the ext4 group when FSTYP == ext3. That way
we will run more tests on those systems which still support the ext3
emulated-by-ext4 mode.)
The shared/002 test could be moved to generic if we had a way for file
systems to declare how many xattrs per file they support.
The shared/006 test needs some way of descriminating which inodes have
a fixed number of inodes, since it fills a small file system until it
runs out of space and then runs fsck on it. Actually, if we make the
test file system smaller, so it runs in finite time, we could probably
just run it on all file systems, since checking to see what file
systems which don't have a fixed inode table (e.g., btrfs) do under
ENOSPC when creating tons of inodes probably makes sense there for
those file systems as well.
I'm not sure why shared/011 is only run on ext4 and btrfs. Does
cgroup-aware writeback not work on other file systems?
The shared/{008,009,010} tests could be moved to generic if we added
_require_dedup. The shared/298 tests just needs a _require_fstrim.
The bottom line is I think if this is something we care about, we can
probably move out nearly all of the tests from shared. Should I start
sending patches? :-)
- Ted
next prev parent reply other threads:[~2019-06-20 16:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 18:40 [PATCH v3 1/2] common/casefold: Add infrastructure to test filename casefold feature Gabriel Krisman Bertazi
2019-06-12 18:40 ` [PATCH v3 2/2] shared/012: Add tests for filename casefolding feature Gabriel Krisman Bertazi
2019-06-16 14:44 ` Eryu Guan
2019-06-16 20:01 ` Theodore Ts'o
2019-06-20 11:29 ` Eryu Guan
2019-06-20 16:21 ` Theodore Ts'o [this message]
2019-06-20 17:50 ` Removing the shared class of tests Darrick J. Wong
2019-06-20 21:46 ` Theodore Ts'o
2019-06-24 7:16 ` Christoph Hellwig
2019-06-24 13:07 ` Theodore Ts'o
2019-06-24 17:05 ` Darrick J. Wong
2019-06-24 17:25 ` Theodore Ts'o
2019-06-26 2:37 ` Eryu Guan
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=20190620162116.GA4650@mit.edu \
--to=tytso@mit.edu \
--cc=fstests@vger.kernel.org \
--cc=guaneryu@gmail.com \
--cc=krisman@collabora.com \
--cc=lakshmipathi.ganapathi@collabora.co.uk \
--cc=linux-ext4@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).