Re: RFC: don't fail tests when mkfs options collide

["Theodore Ts'o" <tytso@mit.edu>]

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

						- Ted