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