linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	Eryu Guan <guaneryu@gmail.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: Mon, 24 Jun 2019 09:07:30 -0400	[thread overview]
Message-ID: <20190624130730.GD1805@mit.edu> (raw)
In-Reply-To: <20190624071610.GA10195@infradead.org>

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)

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

  reply	other threads:[~2019-06-24 13:07 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 [this message]
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=20190624130730.GD1805@mit.edu \
    --to=tytso@mit.edu \
    --cc=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=hch@infradead.org \
    --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).