From: Eryu Guan <guaneryu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Christoph Hellwig <hch@infradead.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Gabriel Krisman Bertazi <krisman@collabora.com>,
fstests@vger.kernel.org, linux-ext4@vger.kernel.org,
"Lakshmipathi.G" <lakshmipathi.ganapathi@collabora.co.uk>
Subject: Re: Removing the shared class of tests
Date: Wed, 26 Jun 2019 10:37:13 +0800 [thread overview]
Message-ID: <20190626023713.GA7943@desktop> (raw)
In-Reply-To: <20190624130730.GD1805@mit.edu>
On Mon, Jun 24, 2019 at 09:07:30AM -0400, Theodore Ts'o wrote:
> On Mon, Jun 24, 2019 at 12:16:10AM -0700, Christoph Hellwig wrote:
> >
> > As for the higher level question? The shared tests always confused the
> > heck out of me. generic with the right feature checks seem like a much
> > better idea.
>
> Agreed. I've sent out a patch series to bring the number of patches
> in shared down to four. Here's what's left:
>
> shared/002 --- needs a feature test to somehow determine whether a
> file system supports thousads of xattrs in a file (currently
> on btrfs and xfs)
Another option would be just whitelist btrfs and xfs in a require rule,
we already have few require rules work like that, e.g.
_fstyp_has_non_default_seek_data_hole(), this is not ideal, but works in
such corner cases.
Thanks,
Eryu
>
> shared/011 --- needs some way of determining that a file system
> supports cgroup-aware writeback (currently enabled only for
> ext4 and btrfs). Do we consider lack of support of
> cgroup-aware writeback a bug? If so, maybe it doesn't need a
> feature test at all?
>
> shared/032 --- needs a feature test to determine whether or not a file
> system's mkfs supports detection of "foreign file systems".
> e.g., whether or not it warns if you try overwrite a file
> system w/o another file system. (Currently enabled by xfs and
> btrfs; it doesn't work for ext[234] because e2fsprogs, because
> I didn't want to break existing shell scripts, only warns when
> it is used interactively. We could a way to force it to be
> activated it points out this tests is fundamentally testing
> implementation choices of the userspace utilities of a file
> system. Does it belong in xfstests? : ¯\_(ツ)_/¯ )
>
> shared/289 --- contains ext4, xfs, and btrfs mechanisms for
> determining blocks which are unallocated. Has hard-coded
> invocations to dumpe2fs, xfs_db, and /bin/btrfs.
>
> These don't have obvious solutions. We could maybe add a _notrun if
> adding the thousands of xattrs fails with an ENOSPC or related error
> (f2fs uses something else).
>
> Maybe we just move shared/011 and move it generic/ w/o a feature test.
>
> Maybe we remove shared/032 altogether, since for e2fsprogs IMHO
> the right place to put it is the regression test in e2fsprogs --- but
> I know xfs has a different test philosophy for xfsprogs; and tha begs
> the question of what to do for mkfs.btrfs.
>
> And maybe we just split up shared/289 to three different tests in
> ext4/, xfs/, and btrfs/, since it would make the test script much
> simpler to understand?
>
> What do people think?
>
> - Ted
prev parent reply other threads:[~2019-06-26 2:37 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 ` Removing the shared class of tests Theodore Ts'o
2019-06-20 17:50 ` 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 [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=20190626023713.GA7943@desktop \
--to=guaneryu@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=hch@infradead.org \
--cc=krisman@collabora.com \
--cc=lakshmipathi.ganapathi@collabora.co.uk \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).