Message-ID: <Z6FFlxFEPfJT0h_P@dread.disaster.area>
Date: Tue, 4 Feb 2025 09:39:19 +1100
From: Dave Chinner <david@...morbit.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
Cc: lsf-pc@...ts.linux-foundation.org, linux-xfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, djwong@...nel.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.

Right, the point of check-parallel is to take away the need to
specify devices completely.  I've already added support for the
LOGWRITES_DEV, and I'm in the process of adding LOGDEV and RTDEV
support for both test and scratch devices. At this point, the need
for actual actual device specification in the config files goes
away.

What I am expecting to need is a set of fields that specify the
*size* of the devices so that the hard-coded image file sizes in
the check-parallel script go away.

>From there, I intend to have check-parallel iterate config file run
sections itself, rather than have it run them internally to check.
That way check is only ever invoked by check-parallel with all the
devices completely set up.

Hence a typical host independent config file would look like:

TEST_DEV_SIZE=10g
TEST_RTDEV_size=10g
TEST_LOGDEV_SIZE=128m
SCRATCH_DEV_SIZE=20g
SCRATCH_RTDEV_size=20g
SCRATCH_LOGDEV_SIZE=512m
LOGWRITES_DEV_SIZE=2g

[xfs]
FSTYP=xfs
MKFS_OPTIONS="-b size=4k"
TEST_FS_MOUNT_OPTIONS=
MOUNT_OPTIONS=
USE_EXTERNAL=

[xfs-rmapbt]
MKFS_OPTIONS="-b size=4k -m rmapbt=1"

[xfs-noreflink]
MKFS_OPTIONS="-b size=4k -m reflink=0"

[xfs-n64k]
MKFS_OPTIONS="-b size=4k -n size=64k"

[xfs-ext]
MKFS_OPTIONS="-b size=4k"
USE_EXTERNAL=yes

[ext4]
FSTYP="ext4"
MKFS_OPTIONS=
USE_EXTERNAL=

[btrfs]
FSTYP="btrfs"
.....


IOWs, all that is different from system to system is the device size
setup. The actual config sections under test (e.g. [xfs]) never need
to change from host to host, nor environment to environment. i.e.
"xfs-n64k" runs the same config filesystem test on every system,
everywhere...

> ** Proposal ** 
> We would like to propose a discussion at LSFMM on two key features: central

I'm not going to be at LSFMM, so please discuss this on the list via
email as we'd normally do so. LSFMM discussions are exclusionary
whilst, OTOH, the mailing list is inclusive...

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

I don't really see a need for a new centralised config setup. With
the above, we can acheived a "zero-config" goal with the existing
config file formats and infrastructure. All that we need to do is
update the default config file in the repo to contain a section for
each of the "standard" test configs we want to define....

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

On of my goals with check-parallel is to completely remove the need
for end users to configure fstests. i.e. all you need to do is point
it at a directory, tell it which filesystem to test, and it "just
runs" with all the defaults that come direct from the fstests
repository...

It is also worth keeping in mind that check-parallel can be run with
a single runner thread, in which case a single check instance runs
all tests serially. i.e. we can make check-parallel emulate existing
check behaviour exactly, except it uses all the
auto-config/auto-setup stuff that comes along with check-parallel...

-Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists