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
