From: "Theodore Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@lst.de>
Cc: Zorro Lang <zlang@kernel.org>, Brian Foster <bfoster@redhat.com>,
fstests@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: remove _supported_fs
Date: Thu, 19 Dec 2024 12:02:12 -0500 [thread overview]
Message-ID: <20241219170212.GA1585694@mit.edu> (raw)
In-Reply-To: <20241210160827.GA26559@lst.de>
On Tue, Dec 10, 2024 at 05:08:27PM +0100, Christoph Hellwig wrote:
> I think the diffstat alone makes it pretty clear that moving away
> form that is a benefit, and it's also a lot easier to understand than
> that ext2 and ext3 magically run ext4 tests.
We talked about this on the weekly ext4 video chat, and I think what
we'd think is actually cleaner is to have a single directory for all
ext2/ext3/ext4 tests, and then eventually, have feature-specific
guards which skip a test if a particular feature isn't supported by a
particular file system.
It's always been my position that ext2, ext3, and ext4 are effectively
the same file system from a conceptual perspective, with multiple
implementations that support different subsets of file system
features. This includes /usr/src/linux/fs/ext2,
/usr/src/linux/fs/ext3 (before we removed it from more recent
rernels), /usr/src/linux/fs/ext4, HURD's implementation of ext2,
NetBSD/FreeBSD's implementation of ext2, etc.
So effectively, what I'm proposing is that we use xfstests/tests/ext4
effectively as "extN", which would be used when testing with
FSTYP=ext[234].
Yes, we'll need to do some cleanup to add feature guards (e.g.,
_require_metadata_journaling, and "_require_scratch_ext4_feature mmp")
instead of _exclude_fs ext2, but in the end, I think this will be
cleaner and easier to understand since we'll know exactly what the
test is testing.
Cheers,
- Ted
prev parent reply other threads:[~2024-12-19 17:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 6:58 remove _supported_fs Christoph Hellwig
2024-12-10 6:58 ` [PATCH 1/4] generic/363: remove _supported_fs xfs Christoph Hellwig
2024-12-10 13:15 ` Brian Foster
2024-12-10 6:58 ` [PATCH 2/4] common: remove the $FSYP check in _cleanup_dump Christoph Hellwig
2024-12-10 6:58 ` [PATCH 3/4] ext-common: create a new test directory for ext* common tests Christoph Hellwig
2024-12-18 15:59 ` Jan Kara
2024-12-23 8:38 ` Christoph Hellwig
2024-12-10 6:58 ` [PATCH 4/4] replace _supported_fs with _exclude_fs Christoph Hellwig
2024-12-10 13:00 ` remove _supported_fs Theodore Ts'o
2024-12-10 16:08 ` Christoph Hellwig
2024-12-19 17:02 ` Theodore Ts'o [this message]
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=20241219170212.GA1585694@mit.edu \
--to=tytso@mit.edu \
--cc=bfoster@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=hch@lst.de \
--cc=linux-ext4@vger.kernel.org \
--cc=zlang@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 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.