Message-ID: <8734fo6uag.fsf@gmail.com>
Date: Sat, 08 Mar 2025 09:35:59 +0530
From: Ritesh Harjani (IBM) <ritesh.list@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>, Ojaswin Mujoo <ojaswin@...ux.ibm.com>
Cc: lsf-pc@...ts.linux-foundation.org, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, dchinner@...hat.com, jack@...e.cz, tytso@....edu, linux-ext4@...r.kernel.org, nirjhar.roy.lists@...il.com, zlang@...nel.org
Subject: Re: [LSF/MM/BPF TOPIC] xfstests: Centralizing filesystem configs and device configs

"Darrick J. Wong" <djwong@...nel.org> writes:

> On Sat, Feb 01, 2025 at 10:23:29PM +0530, Ojaswin Mujoo wrote:
>> Greetings,
>> 
>> This proposal is on behalf of Me, Nirjhar and Ritesh. We would like to submit
>> a proposal on centralizing filesystem and device configurations within xfstests
>> and maybe a further discussion on some of the open ideas listed by Ted here [3].
>> More details are mentioned below.
>> 
>> ** Background ** 
>> There was a discussion last year at LSFMM [1] about creating a central fs-config
>> store, that can then be used by anyone for testing different FS
>> features/configurations. This can also bring an awareness among other developers
>> and testers on what is being actively maintained by FS maintainers. We recently
>> posted an RFC [2] for centralizing filesystem configuration which is under
>> review. The next step we are considering is to centralize device configurations
>> within xfstests itself. In line with this, Ted also suggested a similar idea (in
>> point A) [3], where he proposed specifying the device size for the TEST and
>> SCRATCH devices to reduce costs (especially when using cloud infrastructure) and
>> improve the overall runtime of xfstests.
>> 
>> Recently Dave introduced a feature [4] to run the xfs and generic tests in
>> parallel. This patch creates the TEST and SCRATCH devices at runtime without
>> requiring them to be specified in any config file. However, at this stage, the
>> automatic device initialization appears to be somewhat limited. We believe that
>> centralizing device configuration could help enhance this functionality as well.
>> 
>> ** Proposal ** 
>> We would like to propose a discussion at LSFMM on two key features: central
>> fsconfig and central device-config within xfstests. We can explore how the
>> fsconfig feature can be utilized, and by then, we aim to have a PoC for central
>> device-config feature, which we think can also be discussed in more detail. At
>> this point, we are hoping to get a PoC working with loop devices by default. It
>> will be good to hear from other developers, maintainers, and testers about their
>> thoughts and suggestions on these two features.
>> 
>> Additionally, we would like to thank Ted for listing several features he uses in
>> his custom kvm-xfstests and gce-xfstests [3]. If there is an interest in further
>> reducing the burden of maintaining custom test scripts and wrappers around
>> xfstests, we can also discuss essential features that could be integrated
>> directly into xfstests, whether from Ted's list or suggestions from others.
>> 
>> Thoughts and suggestions are welcome.
>
> Considering all the questions downthread, I'm wondering, are you just
> going to stuff all the known configs into a single configs/default file
> and then modify known_hosts() to set HOST_OPTIONS to that?

In the last approach that's what we were doing. However since check
script only consider 1 exclusive config file for looking into into the
device settings and sections, that forces the users to pass device
settings separately. Not an elegant solution.

>
> 	[ -f /etc/xfsqa.config ]             && export HOST_OPTIONS=/etc/xfsqa.config
> 	[ -f $HOST_CONFIG_DIR/default ]      && export HOST_OPTIONS=$HOST_CONFIG_DIR/default
> 	[ -f $HOST_CONFIG_DIR/$HOST ]        && export HOST_OPTIONS=$HOST_CONFIG_DIR/$HOST
> 	[ -f $HOST_CONFIG_DIR/$HOST.config ] && export HOST_OPTIONS=$HOST_CONFIG_DIR/$HOST.config
>
> Then configs/default contains things like:
>
> [xfs_nocrc]
> MKFS_OPTIONS="-m crc=0"
>
> Would that work for running configurations in this manner:
>
> 	./check -s xfs_nocrc -g all
>
> ?

I am discussing another approach in my last response to Dave. i.e. Let's
maybe define 1 config file for all fs sections e.g. configs/all-fs.config. 
We then need to modify the check script to continue allowing the use of the
HOST_OPTIONS provided config file while also supporting an additional
config file passed via the -c option via cmdline.

That way users can continue to use their local.config file as is but can
also find additional sections to test if they pass 
-c configs/all-fs.config file.

i.e. 

     ./check -c configs/all-fs.config -s xfs_nocrc -g all

where all-fs.config would have defined the [xfs_nocrc] section.

>
> (I am completely ignorant of config files and never use them.)
>

So you have your custom local.config file defined somewhere which you
always use for testing? What's your setup like in terms of different fs
& device configurations to test?
(both your local setup for fstests testing and ci setup which you use)

> --D
>

Thanks Darrick for looking into this :)

-ritesh

>> 
>> ** References **
>> [1] https://lore.kernel.org/all/87h6h4sopf.fsf@doe.com/
>> [2] https://lore.kernel.org/all/9a6764237b900f40e563d8dee2853f1430245b74.1736496620.git.nirjhar.roy.lists@gmail.com/
>> [3] https://lore.kernel.org/all/20250110163859.GB1514771@mit.edu/
>> [4] https://lore.kernel.org/all/20241127045403.3665299-1-david@fromorbit.com/
>> 

Powered by blists - more mailing lists