Re: [LSF/MM/BPF TOPIC] xfstests: Centralizing filesystem configs and device configs

Darrick J. Wong
2025-03-06T18:22:18Z

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?

[ -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 completely ignorant of config files and never use them.)

--D

>
> ** 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/
>