[LSF/MM/BPF TOPIC] File system testing

[LSF/MM/BPF TOPIC] File system testing

[Theodore Tso]

I'd like to propose a perennial favorite file system testing as a
topic for the FS track.  Topics to cover would include:

1) Standardizing test scenarios for various file systems.

   I have test scenarios for ext4 and xfs in my test appliance (e.g.,
   4k, 64k, and 1k blocksizes, with fscrypt enabled, with dax enabled,
   etc.)  But I don't have those for other file systems, such as
   btrfs, etc.  It would be nice if this could be centrally documented
   some where, perhaps in the kernel sources?

2) Standardized way of expressing that certain tests are expected to
   fail for a given test scenario.  Ideally, we can encode this in
   xfstests upstream (an example of this is requiring metadata
   journalling for generic/388).  But in some cases the failure is
   very specific to a particular set of file system configurations,
   and it may vary depending on kernel version (e.g., a problem that
   was fixed in 6.6 and later LTS kernels, but it was too hard to
   backport to earlier LTS kernels).

3) Automating the use of tests to validate file system backports to
   LTS kernels, so that commits which might cause file system
   regressions can be automatically dropped from a LTS rc kernel.

   	       	      		    	    	 - Ted

Re: [LSF/MM/BPF TOPIC] File system testing

[Chuck Lever]

On Wed, Feb 18, 2026, at 10:07 AM, Theodore Tso wrote:
> I'd like to propose a perennial favorite file system testing as a
> topic for the FS track.  Topics to cover would include:
>
> 1) Standardizing test scenarios for various file systems.
>
>    I have test scenarios for ext4 and xfs in my test appliance (e.g.,
>    4k, 64k, and 1k blocksizes, with fscrypt enabled, with dax enabled,
>    etc.)  But I don't have those for other file systems, such as
>    btrfs, etc.  It would be nice if this could be centrally documented
>    some where, perhaps in the kernel sources?
>
> 2) Standardized way of expressing that certain tests are expected to
>    fail for a given test scenario.  Ideally, we can encode this in
>    xfstests upstream (an example of this is requiring metadata
>    journalling for generic/388).  But in some cases the failure is
>    very specific to a particular set of file system configurations,
>    and it may vary depending on kernel version (e.g., a problem that
>    was fixed in 6.6 and later LTS kernels, but it was too hard to
>    backport to earlier LTS kernels).
>
> 3) Automating the use of tests to validate file system backports to
>    LTS kernels, so that commits which might cause file system
>    regressions can be automatically dropped from a LTS rc kernel.

As a subsystem maintainer of kdevops, I'm interested in the topic
of shared FS testing infrastructure. These talking points seem
relevant and valuable.


-- 
Chuck Lever

Re: [LSF/MM/BPF TOPIC] File system testing

[Ric Wheeler]

On 2/18/26 10:07 AM, Theodore Tso wrote:
> I'd like to propose a perennial favorite file system testing as a
> topic for the FS track.  Topics to cover would include:
>
> 1) Standardizing test scenarios for various file systems.
>
>     I have test scenarios for ext4 and xfs in my test appliance (e.g.,
>     4k, 64k, and 1k blocksizes, with fscrypt enabled, with dax enabled,
>     etc.)  But I don't have those for other file systems, such as
>     btrfs, etc.  It would be nice if this could be centrally documented
>     some where, perhaps in the kernel sources?
>
> 2) Standardized way of expressing that certain tests are expected to
>     fail for a given test scenario.  Ideally, we can encode this in
>     xfstests upstream (an example of this is requiring metadata
>     journalling for generic/388).  But in some cases the failure is
>     very specific to a particular set of file system configurations,
>     and it may vary depending on kernel version (e.g., a problem that
>     was fixed in 6.6 and later LTS kernels, but it was too hard to
>     backport to earlier LTS kernels).
>
> 3) Automating the use of tests to validate file system backports to
>     LTS kernels, so that commits which might cause file system
>     regressions can be automatically dropped from a LTS rc kernel.
>
>     	       	      		    	    	 - Ted


This is a very interesting topic to me as well.  I also am interested in 
testing on larger and aged file systems, not just file systems that are 
newly created for test runs....

Ric

Re: [LSF/MM/BPF TOPIC] File system testing

[Hans Holmberg]

On 18/02/2026 16:08, Theodore Tso wrote:
> I'd like to propose a perennial favorite file system testing as a
> topic for the FS track.  Topics to cover would include:
> 
> 1) Standardizing test scenarios for various file systems.
> 
>    I have test scenarios for ext4 and xfs in my test appliance (e.g.,
>    4k, 64k, and 1k blocksizes, with fscrypt enabled, with dax enabled,
>    etc.)  But I don't have those for other file systems, such as
>    btrfs, etc.  It would be nice if this could be centrally documented
>    some where, perhaps in the kernel sources?
> 
> 2) Standardized way of expressing that certain tests are expected to
>    fail for a given test scenario.  Ideally, we can encode this in
>    xfstests upstream (an example of this is requiring metadata
>    journalling for generic/388).  But in some cases the failure is
>    very specific to a particular set of file system configurations,
>    and it may vary depending on kernel version (e.g., a problem that
>    was fixed in 6.6 and later LTS kernels, but it was too hard to
>    backport to earlier LTS kernels).
> 
> 3) Automating the use of tests to validate file system backports to
>    LTS kernels, so that commits which might cause file system
>    regressions can be automatically dropped from a LTS rc kernel.
> 
>    	       	      		    	    	 - Ted
> 
> 

This sounds interesting to me, making more manageable to run sets of
different scenarios (and sharing important ones) would would be great.

Making it easier to compare the results of different runs of different
configurations would also be awesome (making it easy to figure out
if an issue is related to a specific config or a more generic problem)

Cheers,
Hans

Re: [LSF/MM/BPF TOPIC] File system testing

[Carlos Maiolino]

On Wed, Feb 18, 2026 at 10:07:36AM -0500, Theodore Tso wrote:
> I'd like to propose a perennial favorite file system testing as a
> topic for the FS track.  Topics to cover would include:
> 

+1 for the topic.
> 1) Standardizing test scenarios for various file systems.
> 
>    I have test scenarios for ext4 and xfs in my test appliance (e.g.,
>    4k, 64k, and 1k blocksizes, with fscrypt enabled, with dax enabled,
>    etc.)  But I don't have those for other file systems, such as
>    btrfs, etc.  It would be nice if this could be centrally documented
>    some where, perhaps in the kernel sources?
> 
> 2) Standardized way of expressing that certain tests are expected to
>    fail for a given test scenario.  Ideally, we can encode this in
>    xfstests upstream (an example of this is requiring metadata
>    journalling for generic/388).  But in some cases the failure is
>    very specific to a particular set of file system configurations,
>    and it may vary depending on kernel version (e.g., a problem that
>    was fixed in 6.6 and later LTS kernels, but it was too hard to
>    backport to earlier LTS kernels).

IIUC, this might be something that frequently needs to be updated. This
would add more burden to the maintainer with (probably) frequent updates
to update such information.

I wonder if perhaps we could simply use a shared repository
where we can push test results and the respective kernel/xfstests
configuration used? And a section for 'expected/common failures'.

> 
> 3) Automating the use of tests to validate file system backports to
>    LTS kernels, so that commits which might cause file system
>    regressions can be automatically dropped from a LTS rc kernel.

This seems useful for me even for mainline, if a regression has been
found in LTS, it's likely it shouldn't have got into mainline anyway.

Re: [Lsf-pc] [LSF/MM/BPF TOPIC] File system testing

[Jan Kara]

On Tue 24-02-26 13:48:38, Carlos Maiolino via Lsf-pc wrote:
> > 3) Automating the use of tests to validate file system backports to
> >    LTS kernels, so that commits which might cause file system
> >    regressions can be automatically dropped from a LTS rc kernel.
> 
> This seems useful for me even for mainline, if a regression has been
> found in LTS, it's likely it shouldn't have got into mainline anyway.

This often isn't true. Rather often the failure in LTS means patches
implicitely depend on some change that's missing from LTS...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR