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@xxxxxxx/ > [2] https://lore.kernel.org/all/9a6764237b900f40e563d8dee2853f1430245b74.1736496620.git.nirjhar.roy.lists@xxxxxxxxx/ > [3] https://lore.kernel.org/all/20250110163859.GB1514771@xxxxxxx/ > [4] https://lore.kernel.org/all/20241127045403.3665299-1-david@xxxxxxxxxxxxx/ >
