On Fri, Jan 10, 2025 at 09:10:28AM +0000, Nirjhar Roy (IBM) wrote:
> This adds support to pick and use any existing FS config from
> configs/<fstype>/<config>. e.g.
>
> configs/xfs/1k
> configs/xfs/4k
> configs/ext4/4k
> configs/ext4/64k
>
> This should help us maintain and test different fs test
> configurations from a central place. We also hope that
> this will be useful for both developers and testers to
> look into what is being actively maintained and tested
> by FS Maintainers.
I haven't been using the current in-place configs in kvm-xfstests and
gce-xfstests because there are number of things that my setup can
support that xfstests native config doesn't support (and becuase my
system predates the FS config setup). I don't mind just using my own
custom setup, but if we can keep feature parity, perhaps someday I can
switch over to xfstests's system. This might also make it easier for
people to more easily test using the same setup as the FS maintainers,
regardless of which test running infrastructure they are using.
A) A way of specifying the minimum device size needed for the TEST and
SCRATCH device. Using a smaller file system size reduces test
run time, and if you are paying for cloud test infrastructure,
the size of the Google Persistent Disk or Amazon Elastic Block
Storage has a direct impact on the cost per test, which in turn
impacts how many tests we can afford to run. But for certain
test configurations, such as using a larger block size, or using
bigalloc, a larger test device size might be needed in order for
tests to be able to run correctly.
B) A way of specifying test exclusions, both at a global level, or on
a per-fs, or on a per-configuration basis. It should also be
possible to specify the kernel version being tested, and so
that certain test exclusions might only be done when testing
LTS kernels (for example):
#if LINUX_VERSION_CODE < KERNEL_VERSION(6,6,30)
// This test failure is fixed by commit 631426ba1d45q ("mm/madvise:
// make MADV_POPULATE_(READ|WRITE) handle VM_FAULT_RETRY properly"),
// which first landed in v6.9, and was backported to 6.6.30 as commit
// 631426ba1d45. Unfortunately, it's too involved to backport it and its
// dependencies to the 6.1 or earlier LTS kernels
generic/743
#endif
C) A way to run shell functions to do setups for testing things like
overlayfs, or nfs (where I may be starting separate VM's for
the NFS server, or needing to find the IP address for the NFS
server running the appropriate kernel under test, which either
been the same as the kernel under test, or which might be some
standard server version, such as a RHEL or SLES kernel), as
part of the setup and teardown of a particular test
configuration.
D) I also have a really nice scheme for specifying a mkfs
configuration for testing LTS kernels, since I use the same
test appliance for testing upstream and LTS/product kernels,
and the latest mkfs.xfs will produce a file system image that
isn't supported by a 5.15 LTS kernel. Product teams might
also want to run tests using the mkfs configuration for that
era kernel, even if a 6.1 kernel can support a file system
created using the latest version of xfsprogs or e2fsprogs.
Doing this is a bit non-trivial due to a misfeature of how
mkfs.xfs works, but I have a workaround that some might find
useful here:
https://github.com/tytso/xfstests-bld/commit/f62433b74146e6ecacdeace306828c6c7510c4a6
Note that this might also be useful for xfstests, where
specific xfstests scripts have to handle cases where mkfs.xfs
might unexpectedly fail due to an unfortunate combination
between the test-specific _scratch_mkfs options, and the
global MKFS_OPTIONS. This never happens with ext4, due to how
mkfs.ext4 handles conflicting command-line options, but it
*is* a problem with mkfs.xfs. If you think merging an 150
line shell script library is easier than trying to get
consensus from within the xfs community, here's a technical
workaround to what might be charitably described as a
disagreement between the xfs architects and the needs of the
testing community. :-)
If we're going to have critical mass, maybe this is something that's
worth discussing at the upcoming LSF/MM? As I said, I'm happy having
this be an exclusive feature in gce-xfstests and kvm-xfstests, but
perhaps it would make sense to uplevel some of this feature into
xfstests so that more people can take advantage of it, and to make it
easier for us to share test configs across test teams and upstream
developers?
Cheers,
- Ted
