From: David Sterba <dsterba@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Zorro Lang <zlang@redhat.com>, Anand Jain <anand.jain@oracle.com>,
fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
fdmanana@kernel.org
Subject: Re: [PATCH v2 1/2] shared: move btrfs clone device testcase to the shared group
Date: Wed, 20 Mar 2024 17:08:02 +0100 [thread overview]
Message-ID: <20240320160802.GE14596@suse.cz> (raw)
In-Reply-To: <Zfn412vXi8V7Sqd3@infradead.org>
On Tue, Mar 19, 2024 at 01:43:03PM -0700, Christoph Hellwig wrote:
> On Tue, Mar 19, 2024 at 12:16:33PM +0800, Zorro Lang wrote:
> > I didn't suggest to make it a shared case directly, I asked if there's a
> > _require_xxxx helper to make this case notrun on "not proper" fs, not
> > just use "btrfs ext4" to be whitelist :
> >
> > https://lore.kernel.org/fstests/20240312044629.hpaqdkl24nxaa3dv@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com/
> >
> > In my personal opinion, the "shared" directory is a place to store the cases
> > which are nearly to be generic, but not ready. It's a place to remind us
> > there're still some cases use something likes "supported btrfs ext4" as the
> > hard condition of _notrun, rather than a flexible _require_xxx helper. These
> > cases in shared better to be moved to generic, if we can improve it in one day.
> >
> > It more likes a "TODO" list of generic. If we just write it in generic/
> > directory, I'm afraid we'll leave it in hundreds of generic cases then forget it.
> >
> > What do you think?
>
> I like we're you're going, but I'd like to take it a step further:
>
> I think we should just kill _supported_fs entirely.
>
> tests/$FSTYPE is run for $FSTYP only, period.
> tests/generic/ is run for all file systems, and run/notrun deciѕions
> should be based on feature checks. Where they can't happen without
> fs-sepcific infrastructure we need a _require/_have check that
> switches on $FSTYP like we already have in many places.
This could work, the number of exceptions is short:
tests/generic:
547 _supported_fs generic
4 _supported_fs ^nfs
2 _supported_fs ^overlay
1 _supported_fs ^xfs
1 _supported_fs ^btrfs ^nfs
1 _supported_fs ^btrfs
The example from generic/187:
# btrfs can't fragment free space. This test is unreliable on NFS, as it
# depends on the exported filesystem.
_supported_fs ^btrfs ^nfs
There are different reasons for the exclusion but at least for btrfs
could be transformed to e.g.
_require_can_fragment_free_space
Not sure about the NFS part, it can be either excluding remote
filesystems or mandating a local one.
next prev parent reply other threads:[~2024-03-20 16:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-16 17:02 [PATCH v2 0/2] fstests: new test cases for generic group Anand Jain
2024-03-16 17:02 ` [PATCH v2 1/2] shared: move btrfs clone device testcase to the shared group Anand Jain
2024-03-18 22:02 ` David Sterba
2024-03-18 22:15 ` Christoph Hellwig
2024-03-19 4:16 ` Zorro Lang
2024-03-19 17:17 ` Anand Jain
2024-03-19 17:27 ` David Sterba
2024-03-19 20:43 ` Christoph Hellwig
2024-03-20 16:08 ` David Sterba [this message]
2024-03-21 21:41 ` Christoph Hellwig
2024-04-09 14:43 ` Anand Jain
2024-03-16 17:02 ` [PATCH v2 2/2] generic: test mount fails on physical device with configured dm volume Anand Jain
2024-03-24 8:49 ` Anand Jain
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=20240320160802.GE14596@suse.cz \
--to=dsterba@suse.cz \
--cc=anand.jain@oracle.com \
--cc=fdmanana@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=zlang@redhat.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.