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@xxxxxxxxxxxxx
