On 2/3/25 01:30, Ritesh Harjani (IBM) wrote:
Anand Jain <anand.jain@xxxxxxxxxx> writes:
On 10/1/25 17:10, Nirjhar Roy (IBM) wrote:
This adds support to pick and use any existing FS config from
configs/<fstype>/<config>. e.g.
configs/xfs/1k
configs/xfs/4k
configs/ext4/4k
configs/ext4/64k
This should help us maintain and test different fs test
configurations from a central place. We also hope that
this will be useful for both developers and testers to
look into what is being actively maintained and tested
by FS Maintainers.
When we will have fsconfigs set, then will be another subdirectory created
in results/<section>. For example let's look at the following:
The directory tree structure on running
sudo ./check -q 2 -R xunit-quiet -c xfs/4k,configs/xfs/1k selftest/001 selftest/007
The -c option check makes sense to me. Is it possible to get this
feature implemented first while the -q option is still under discussion?
Hi Anand,
Thanks for trying the patches. The design of -c option is still under
discussion [1]. But it will be helpful if you could help us understand
your reasons for finding -c option useful :)
Reason is exactly same as you mentioned and I copied it here:
---
1. Testers and other FS developers can know what is being actively
tested and maintained by FS Maintainers.
---
[1]: https://lore.kernel.org/linux-fsdevel/Z55RXUKB5O5l8QjM@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
That said, I have a suggestion for the -c option—
Global config variables should be overridden by file system-specific
config files.
For example, if configs/localhost.config contains:
MKFS_OPTIONS="--sectorsize 64K"
but configs/<fstype>/some_config sets:
MKFS_OPTIONS=""
then the value from configs/<fstype>/some_config should take priority.
I ran some tests with btrfs, and I don’t see this behavior happening yet.
I think that was intentional. I guess the reasoning was, we don't want to
break use cases for folks who still wanted to use local.config file
option.
Ok.
However, in the new proposed design [2] we are thinking of having 1
large config per filesystem. e.g. configs/btrfs/config.btrfs which will
define all of the relevant sections e.g. btrfs_4k, btrfs_64k, ... Then
on invokking "make", it will generate a single large fs config file i.e.
configs/.all-sections-configs which will club all filesystems section
configs together.
Now when someone invokes check script with different -s options, it will
first look into local.config file, if local.config not found, then it
will look into configs/.all-sections-configs to get the relevant section
defines.
This hopefully should address all the other concerns which were raised
on the current central fs config design.
[2]: https://lore.kernel.org/linux-fsdevel/87plj0hp7e.fsf@xxxxxxxxx/
I think it’s making things a bit more complicated than needed.
True. We’d probably be better off with one big config file.
No need for <fstype> directories under configs.
configs/<fstype>.config should work just fine.
I’m not fond of the need to run make; it seems excessive.
The way to run it is simple and works well:
$ ./check -c configs/btrfs.config
$ ./check -c configs/btrfs.config -s <section1> ...
$ ./check -c configs/btrfs.config -S <exclude-section1> ...
These steps already work fine:
$ cp configs/btrfs.config configs/$(hostname).config
$ ./check -s <section> ..
(Patch containing configs/btrfs.config is already in the ML).
Also, a --dry-run option to check the config before running would
be super helpful.
Thanks, Anand
-ritesh
Thanks, Anand
