All of lore.kernel.org
 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 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.