From: "Darrick J. Wong" <djwong@kernel.org>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, dchinner@redhat.com,
ritesh.list@gmail.com, jack@suse.cz, tytso@mit.edu,
linux-ext4@vger.kernel.org, nirjhar.roy.lists@gmail.com,
zlang@kernel.org
Subject: Re: [LSF/MM/BPF TOPIC] xfstests: Centralizing filesystem configs and device configs
Date: Thu, 6 Mar 2025 10:22:17 -0800 [thread overview]
Message-ID: <20250306182217.GB2803730@frogsfrogsfrogs> (raw)
In-Reply-To: <Z55RXUKB5O5l8QjM@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
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/
>
next prev parent reply other threads:[~2025-03-06 18:22 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-01 16:53 [LSF/MM/BPF TOPIC] xfstests: Centralizing filesystem configs and device configs Ojaswin Mujoo
2025-02-03 22:39 ` Dave Chinner
2025-02-04 7:14 ` Ritesh Harjani
2025-02-04 22:13 ` Dave Chinner
2025-03-01 13:09 ` Ritesh Harjani
2025-03-01 13:17 ` Ritesh Harjani
2025-03-04 21:45 ` Dave Chinner
2025-03-05 3:43 ` Ritesh Harjani
2025-03-05 23:20 ` Dave Chinner
2025-03-08 3:26 ` Ritesh Harjani
2025-03-06 18:22 ` Darrick J. Wong [this message]
2025-03-08 4:05 ` Ritesh Harjani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250306182217.GB2803730@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=dchinner@redhat.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=nirjhar.roy.lists@gmail.com \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox