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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250306182217.GB2803730@frogsfrogsfrogs>
Date: Thu, 6 Mar 2025 10:22:17 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: 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,
	ritesh.list@...il.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

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