Message-ID: <20250110163859.GB1514771@mit.edu>
Date: Fri, 10 Jan 2025 11:38:59 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@...il.com>
Cc: fstests@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-xfs@...r.kernel.org, ritesh.list@...il.com,
        ojaswin@...ux.ibm.com, djwong@...nel.org, zlang@...nel.org
Subject: Re: [RFC 4/5] check,common/config: Add support for central fsconfig

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

Powered by blists - more mailing lists