All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
	Lang Zorro <zlang@kernel.org>, Carlos Maiolino <cem@kernel.org>,
	Norbert Szetei <norbert@doyensec.com>,
	linux-xfs@vger.kernel.org, Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH] xfs: add regression test for swapext reflux
Date: Mon, 12 Oct 2026 05:00:08 -0700	[thread overview]
Message-ID: <aszLyDHmUXXprhyR@infradead.org> (raw)
In-Reply-To: <c23434c9-0d06-4390-ba2b-0feaf7d747f9@sandeen.net>

On Sat, Oct 10, 2026 at 03:57:19PM -0500, Eric Sandeen wrote:
> > 
> > And, uh, you could turn on exchrange in your test config like I do,
> > especially seeing as it's been enabled by default for a year.
> Sure. Lots of people run xfstests, sometimes even on older releases! If this test is
> specifically designed to test something that requires exchrange, it could make sure
> it sets up the test to do that whenever possible, even if not default or in an
> environment var.
> 
> I'm not actually sure what the overarching fstests philosophy is here, though.

There's not overall philosophy, and that's a bit of a problem.

Whenver we have tests and the config specifying mkfs options, there's
a chance of conflict, and we're very inconsistent in dealing with them.
I think this test would probably also run into that if someone were
testing say a v4 fs config.

I've tried a few things to clear this up, but it's all been bandaids
so far.  I think the only clean way to deal with this would be to
split test into difference categories:

  1) "macro" tests, using TEST_DIR and SCRATCH_DEV using paramters in
     the config, and not specifying their own mkfs overrides
  2) "micro" tests using SCRATCH_DEV using their own paramters, but
     not those from the enviroment
  3) "supermicro" test using their own synthetic loop/scsi_debug/etc
     device not using the option from the config file.  Or at least
     using new and different options just applying to those tests

Getting this right will be a lot of work, though.

  reply	other threads:[~2026-10-12 12:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 17:02 [PATCH v2] xfs: fix exchange-range-to-eof file size exchange Darrick J. Wong
2026-10-07 17:04 ` [PATCH] xfs: add regression test for exchangerange-to-eof reflux Darrick J. Wong
2026-10-07 17:05 ` [PATCH] xfs: add regression test for swapext reflux Darrick J. Wong
2026-10-09 16:13   ` Eric Sandeen
2026-10-09 22:11     ` Darrick J. Wong
2026-10-10  6:09       ` Eric Sandeen
2026-10-10 15:41         ` Darrick J. Wong
2026-10-10 20:57           ` Eric Sandeen
2026-10-12 12:00             ` Christoph Hellwig [this message]
2026-10-07 20:35 ` [PATCH v2] xfs: fix exchange-range-to-eof file size exchange Dave Chinner
2026-10-12 15:07 ` Carlos Maiolino

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=aszLyDHmUXXprhyR@infradead.org \
    --to=hch@infradead.org \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=norbert@doyensec.com \
    --cc=sandeen@sandeen.net \
    --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.