All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.