From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Christoph Hellwig <hch@lst.de>, Zorro Lang <zlang@kernel.org>,
fstests@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: RFC: don't fail tests when mkfs options collide
Date: Fri, 26 Jul 2024 09:20:14 -0700 [thread overview]
Message-ID: <20240726162014.GQ103020@frogsfrogsfrogs> (raw)
In-Reply-To: <20240723141724.GB2333818@mit.edu>
On Tue, Jul 23, 2024 at 10:17:24AM -0400, Theodore Ts'o wrote:
> On Tue, Jul 23, 2024 at 03:39:04PM +0200, Christoph Hellwig wrote:
> >
> > At least in my case it's not really by overriding. E.g. if I force
> > an allocation group (or block group in extN terms) to a specific size
> > and then want a log that is larger than that, changing the AG size
> > is generally a bad idea, and a clear warning to the user is simply the
> > better interface.
>
> Is it just "a bad idea", or "it won't work"? I can imagine that
> sometimes we want to have tests that do things that are generally a
> bad idea, but it's the best way to force a particular corner case to
> happen without having to run the test gazillions of times?
>
> I do remember some cases where when we were using a 1k block size, the
> test wouldn't actually work because the file system needed to be
> bigger or the metadata overhead ended up causing an ENOSPC too early,
> or something weird like that. So that was a case were the merging
> would _work_, and in fact was testing a combination that we actually
> wanted to test --- but we had to adjust the test subtly so it would
> work both on a 4k block size and a 1k block size. I don't remember
> which test it was, or we hacked it, but I'm fairly certain it's
> something we've done before. It's messy.
>
> > Merging the options is what we're currently doing, and it works ok
> > most of the time. The question is what to do when it doesn't.
>
> No matter what, it seems like we'll have to look at each of these
> tests and treat them on a per-case basis. We could have options which
> allows the test to specify that it shouldn't be merging; but then we'd
> still have to decide what we need to do. And what do we do if we
> don't want to merge for ext4 and xfs, but it would be useful for btrfs
> (for example) to merge the options. It's probably also going to
> depend on which test scenarios that various file system developers'
> test setups choose to use....
The big question I have is: for at least the standard -g all runs, does
this decrease the number of tests selected? AFAICT all it does is
converts mkfs option parsing _fail into _notrun, but a 35k shell script
patch is a lot to take in.
If it doesn't change the number of tests selected to run then I think
I'm ok with this.
--D
next prev parent reply other threads:[~2024-07-26 16:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 0:00 RFC: don't fail tests when mkfs options collide Christoph Hellwig
2024-07-23 0:00 ` [PATCH 1/4] common: _notrun if _scratch_mkfs_sized failed Christoph Hellwig
2024-07-23 0:00 ` [PATCH 2/4] common: _notrun if _scratch_mkfs_xfs failed Christoph Hellwig
2024-07-26 17:14 ` Zorro Lang
2024-07-26 18:11 ` Christoph Hellwig
2024-07-28 14:54 ` Zorro Lang
2024-07-29 14:17 ` Christoph Hellwig
2024-07-23 0:00 ` [PATCH 3/4] xfs/432: use _scratch_mkfs_xfs Christoph Hellwig
2024-07-23 0:00 ` [PATCH 4/4] xfs/516: " Christoph Hellwig
2024-07-23 3:50 ` RFC: don't fail tests when mkfs options collide Theodore Ts'o
2024-07-23 13:39 ` Christoph Hellwig
2024-07-23 14:17 ` Theodore Ts'o
2024-07-23 14:20 ` Christoph Hellwig
2024-07-26 16:20 ` Darrick J. Wong [this message]
2024-07-26 17:11 ` Christoph Hellwig
2024-07-28 2:24 ` Darrick J. Wong
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=20240726162014.GQ103020@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
--cc=tytso@mit.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox