Should we consider disable generic/563 for file systems that do not support cgroup2?

Should we consider disable generic/563 for file systems that do not support cgroup2?

[Viacheslav Dubeyko]

Hello,

As far as I can see, the generic/563 test is dedicated to cgroup v2
functionality. And several file systems fails to execute the test:

sudo ./check generic/563
FSTYP         -- hfsplus
PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55 SMP
PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
MKFS_OPTIONS  -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/563        - output mismatch (see xfstests-
dev/results//generic/563.out.bad)
    --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -0700
    +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
11:33:14.231562955 -0700
    @@ -4,11 +4,13 @@
     write is in range
     write -> read/write
     read is in range
    -write is in range
    +write has value of 0
    +write is NOT in range 15938355.2 .. 17616076.8
     read is in range
    ...
    (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
dev/results//generic/563.out.bad'  to see the entire diff)
Ran: generic/563
Failures: generic/563
Failed 1 of 1 tests

sudo ./check generic/563
FSTYP         -- vfat
PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55 SMP
PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
MKFS_OPTIONS  -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/563        - output mismatch (see xfstests-
dev/results//generic/563.out.bad)
    --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -0700
    +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
11:36:02.221320239 -0700
    @@ -1,14 +1,19 @@
     QA output created by 563
     read/write
    -read is in range
    +read has value of 22014464
    +read is NOT in range 15938355.2 .. 17616076.8
     write is in range
     write -> read/write
    ...
    (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
dev/results//generic/563.out.bad'  to see the entire diff)
Ran: generic/563
Failures: generic/563
Failed 1 of 1 tests

sudo ./check generic/563
FSTYP         -- nilfs2
PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55 SMP
PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
MKFS_OPTIONS  -- /dev/loop51
MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch

generic/563        - output mismatch (see xfstests-
dev/results//generic/563.out.bad)
    --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -0700
    +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
11:37:57.633280743 -0700
    @@ -1,14 +1,18 @@
     QA output created by 563
     read/write
     read is in range
    -write is in range
    +write has value of 0
    +write is NOT in range 15938355.2 .. 17616076.8
     write -> read/write
    ...
    (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
dev/results//generic/563.out.bad'  to see the entire diff)
Ran: generic/563
Failures: generic/563
Failed 1 of 1 tests

Should file system (like HFS/HFS+, for example) implement cgroup2 support to
pass the  generic/563 successfully? Is it generic enough test-case? Should we
consider disable generic/563 for file systems that do not support cgroup2?

Thanks,
Slava.

Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

[Zorro Lang]

On Fri, Jul 10, 2026 at 07:10:43PM +0000, Viacheslav Dubeyko wrote:
> Hello,
> 
> As far as I can see, the generic/563 test is dedicated to cgroup v2
> functionality. And several file systems fails to execute the test:
> 
> sudo ./check generic/563
> FSTYP         -- hfsplus
> PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55 SMP
> PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
> MKFS_OPTIONS  -- /dev/loop51
> MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> 
> generic/563        - output mismatch (see xfstests-
> dev/results//generic/563.out.bad)
>     --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -0700
>     +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
> 11:33:14.231562955 -0700
>     @@ -4,11 +4,13 @@
>      write is in range
>      write -> read/write
>      read is in range
>     -write is in range
>     +write has value of 0
>     +write is NOT in range 15938355.2 .. 17616076.8
>      read is in range
>     ...
>     (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
> dev/results//generic/563.out.bad'  to see the entire diff)
> Ran: generic/563
> Failures: generic/563
> Failed 1 of 1 tests
> 
> sudo ./check generic/563
> FSTYP         -- vfat
> PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55 SMP
> PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
> MKFS_OPTIONS  -- /dev/loop51
> MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> 
> generic/563        - output mismatch (see xfstests-
> dev/results//generic/563.out.bad)
>     --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -0700
>     +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
> 11:36:02.221320239 -0700
>     @@ -1,14 +1,19 @@
>      QA output created by 563
>      read/write
>     -read is in range
>     +read has value of 22014464
>     +read is NOT in range 15938355.2 .. 17616076.8
>      write is in range
>      write -> read/write
>     ...
>     (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
> dev/results//generic/563.out.bad'  to see the entire diff)
> Ran: generic/563
> Failures: generic/563
> Failed 1 of 1 tests
> 
> sudo ./check generic/563
> FSTYP         -- nilfs2
> PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55 SMP
> PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
> MKFS_OPTIONS  -- /dev/loop51
> MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> 
> generic/563        - output mismatch (see xfstests-
> dev/results//generic/563.out.bad)
>     --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -0700
>     +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
> 11:37:57.633280743 -0700
>     @@ -1,14 +1,18 @@
>      QA output created by 563
>      read/write
>      read is in range
>     -write is in range
>     +write has value of 0
>     +write is NOT in range 15938355.2 .. 17616076.8
>      write -> read/write
>     ...
>     (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
> dev/results//generic/563.out.bad'  to see the entire diff)
> Ran: generic/563
> Failures: generic/563
> Failed 1 of 1 tests
> 
> Should file system (like HFS/HFS+, for example) implement cgroup2 support to
> pass the  generic/563 successfully? Is it generic enough test-case? Should we
> consider disable generic/563 for file systems that do not support cgroup2?

Hi Viacheslav,

I completely understand your frustration. The "generic" test suite in fstests
isn't a universal requirement document, so I can't really answer whether HFS+
should support cgroup2 or not..

File systems that are not supported by fstests good enough, frequently run into
false failures. When facing a test that is "destined" to fail on a specific
$FSTYP, you have below options (maybe more):

1. You can add this specific test (e.g., generic/563) to your daily local test
   exclusion list, refer to the -e or -E options with the ./check script.

2. You can modify the test case to explicitly skip a specific $FSTYP using the
   _exclude_fs helper, along with a short comment explaining why.

3. You can use or implement a _require_ function to check if a specific feature
   is supported, which will gracefully _notrun the test if it's missing. While
   _require_cgroup2() already exists, its granularity is currently too coarse to
   _notrun for HFS. You might want to consider refining it or introducing a new
   helper to help file systems like HFS+ _notrun properly.

I hope my reply help to clear something for you, please let me know if you have
any further questions.

Thanks,
Zorro

> 
> Thanks,
> Slava.

Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

[Viacheslav Dubeyko]

On Sat, 2026-07-18 at 00:19 +0800, Zorro Lang wrote:
> On Fri, Jul 10, 2026 at 07:10:43PM +0000, Viacheslav Dubeyko wrote:
> > Hello,
> > 
> > As far as I can see, the generic/563 test is dedicated to cgroup v2
> > functionality. And several file systems fails to execute the test:
> > 
> > sudo ./check generic/563
> > FSTYP         -- hfsplus
> > PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55
> > SMP
> > PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
> > MKFS_OPTIONS  -- /dev/loop51
> > MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> > 
> > generic/563        - output mismatch (see xfstests-
> > dev/results//generic/563.out.bad)
> >     --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -
> > 0700
> >     +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
> > 11:33:14.231562955 -0700
> >     @@ -4,11 +4,13 @@
> >      write is in range
> >      write -> read/write
> >      read is in range
> >     -write is in range
> >     +write has value of 0
> >     +write is NOT in range 15938355.2 .. 17616076.8
> >      read is in range
> >     ...
> >     (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
> > dev/results//generic/563.out.bad'  to see the entire diff)
> > Ran: generic/563
> > Failures: generic/563
> > Failed 1 of 1 tests
> > 
> > sudo ./check generic/563
> > FSTYP         -- vfat
> > PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55
> > SMP
> > PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
> > MKFS_OPTIONS  -- /dev/loop51
> > MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> > 
> > generic/563        - output mismatch (see xfstests-
> > dev/results//generic/563.out.bad)
> >     --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -
> > 0700
> >     +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
> > 11:36:02.221320239 -0700
> >     @@ -1,14 +1,19 @@
> >      QA output created by 563
> >      read/write
> >     -read is in range
> >     +read has value of 22014464
> >     +read is NOT in range 15938355.2 .. 17616076.8
> >      write is in range
> >      write -> read/write
> >     ...
> >     (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
> > dev/results//generic/563.out.bad'  to see the entire diff)
> > Ran: generic/563
> > Failures: generic/563
> > Failed 1 of 1 tests
> > 
> > sudo ./check generic/563
> > FSTYP         -- nilfs2
> > PLATFORM      -- Linux/x86_64 hfsplus-testing-0001 7.2.0-rc1+ #55
> > SMP
> > PREEMPT_DYNAMIC Fri Jul 10 11:21:38 PDT 2026
> > MKFS_OPTIONS  -- /dev/loop51
> > MOUNT_OPTIONS -- /dev/loop51 /mnt/scratch
> > 
> > generic/563        - output mismatch (see xfstests-
> > dev/results//generic/563.out.bad)
> >     --- tests/generic/563.out	2026-04-07 14:19:04.785079940 -
> > 0700
> >     +++ xfstests-dev/results//generic/563.out.bad	2026-07-10
> > 11:37:57.633280743 -0700
> >     @@ -1,14 +1,18 @@
> >      QA output created by 563
> >      read/write
> >      read is in range
> >     -write is in range
> >     +write has value of 0
> >     +write is NOT in range 15938355.2 .. 17616076.8
> >      write -> read/write
> >     ...
> >     (Run 'diff -u xfstests-dev/tests/generic/563.out xfstests-
> > dev/results//generic/563.out.bad'  to see the entire diff)
> > Ran: generic/563
> > Failures: generic/563
> > Failed 1 of 1 tests
> > 
> > Should file system (like HFS/HFS+, for example) implement cgroup2
> > support to
> > pass the  generic/563 successfully? Is it generic enough test-case?
> > Should we
> > consider disable generic/563 for file systems that do not support
> > cgroup2?
> 
> Hi Viacheslav,
> 
> I completely understand your frustration. The "generic" test suite in
> fstests
> isn't a universal requirement document, so I can't really answer
> whether HFS+
> should support cgroup2 or not..
> 
> File systems that are not supported by fstests good enough,
> frequently run into
> false failures. When facing a test that is "destined" to fail on a
> specific
> $FSTYP, you have below options (maybe more):
> 
> 1. You can add this specific test (e.g., generic/563) to your daily
> local test
>    exclusion list, refer to the -e or -E options with the ./check
> script.
> 
> 2. You can modify the test case to explicitly skip a specific $FSTYP
> using the
>    _exclude_fs helper, along with a short comment explaining why.
> 
> 3. You can use or implement a _require_ function to check if a
> specific feature
>    is supported, which will gracefully _notrun the test if it's
> missing. While
>    _require_cgroup2() already exists, its granularity is currently
> too coarse to
>    _notrun for HFS. You might want to consider refining it or
> introducing a new
>    helper to help file systems like HFS+ _notrun properly.
> 
> I hope my reply help to clear something for you, please let me know
> if you have
> any further questions.
> 
> 

Hi Zorro,

Thanks for this explanation. I decided to take a deeper look into the
HFS+ related issue to better understand the root case. When I'll have
clear understanding what is going on in generic/563, then I'll be able
to select the proper solution. Currently, I haven't really good
understanding of the root case of issue for HFS+ case. Let me spend
more time on this. :)

Thanks,
Slava.

Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

[Theodore Tso]

On Sat, Jul 18, 2026 at 12:19:52AM -0500, Zorro Lang wrote:
> 
> 3. You can use or implement a _require_ function to check if a specific feature
>    is supported, which will gracefully _notrun the test if it's missing. While
>    _require_cgroup2() already exists, its granularity is currently too coarse to
>    _notrun for HFS. You might want to consider refining it or introducing a new
>    helper to help file systems like HFS+ _notrun properly.

It may be rather challenging to determine whether the file system is
supposed to support cgroupv2, unless we want to define a VFS specific
flag and a way to query it via sysfs.  If we want to encourage the use
of the simpler file systems to use xfstests, we may want to consider
that approach.

						- Ted

Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

[Zorro Lang]

On Sun, Jul 19, 2026 at 10:02:47AM -0400, Theodore Tso wrote:
> On Sat, Jul 18, 2026 at 12:19:52AM -0500, Zorro Lang wrote:
> > 
> > 3. You can use or implement a _require_ function to check if a specific feature
> >    is supported, which will gracefully _notrun the test if it's missing. While
> >    _require_cgroup2() already exists, its granularity is currently too coarse to
> >    _notrun for HFS. You might want to consider refining it or introducing a new
> >    helper to help file systems like HFS+ _notrun properly.
> 
> It may be rather challenging to determine whether the file system is
> supposed to support cgroupv2, unless we want to define a VFS specific
> flag and a way to query it via sysfs.  If we want to encourage the use
> of the simpler file systems to use xfstests, we may want to consider
> that approach.

Hi Ted,

Thank you for your reply. You are right. I was just listing some possible
options, and I did not mean we must change the kernel for testing. Changing
the kernel just for a _notrun is indeed not worth it. If there is no simple
way to implement the _require_* function, we can `_exclude_fs hfs` directly :)

Thanks,
Zorro

> 
> 						- Ted
> 

Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

[Theodore Tso]

On Sun, Jul 19, 2026 at 11:57:04PM -0500, Zorro Lang wrote:
> Thank you for your reply. You are right. I was just listing some
> possible options, and I did not mean we must change the kernel for
> testing. Changing the kernel just for a _notrun is indeed not worth
> it. If there is no simple way to implement the _require_* function,
> we can `_exclude_fs hfs` directly :)

I wouldn't necessarily rule out changing the kernel so that file
systems can declare whether they can support cgroupv2.  The advantage
is that we wouldn't need to keep adding "_exclude_fs xxx" each time we
try to make fstets work on the simpler file systems.  It also means
that if a file system adds support for cgroupv2, we wouldn't need to
change fstests --- also, if the patch gets backported to an older
kernel (either an LTS or an enterprise distro kernel) we don't need to
try to modulate the _exclude_fs using kernel version numbers (which
isn't guaranteed to work given the backporting possibility).

This is a philosophical issue, and reasonable people could disagree on
this approach.  For my part, I created /sys/fs/ext4/features/*
precisely so that userspace (and fstests) so we can test if a
particular feature is available on a particular kernel.  Otherwise, a
test to see whether a particular feature "works" might have a false
positive if the feature is broken, and the way we test whether the
feature is present is basically what was accidentally broken with by a
regression.

Cheers,

					- Ted

Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

[Zorro Lang]

On Sun, Jul 19, 2026 at 12:52:50PM -0400, Theodore Tso wrote:
> On Sun, Jul 19, 2026 at 11:57:04PM -0500, Zorro Lang wrote:
> > Thank you for your reply. You are right. I was just listing some
> > possible options, and I did not mean we must change the kernel for
> > testing. Changing the kernel just for a _notrun is indeed not worth
> > it. If there is no simple way to implement the _require_* function,
> > we can `_exclude_fs hfs` directly :)
> 
> I wouldn't necessarily rule out changing the kernel so that file
> systems can declare whether they can support cgroupv2.  The advantage
> is that we wouldn't need to keep adding "_exclude_fs xxx" each time we
> try to make fstets work on the simpler file systems.  It also means
> that if a file system adds support for cgroupv2, we wouldn't need to
> change fstests --- also, if the patch gets backported to an older
> kernel (either an LTS or an enterprise distro kernel) we don't need to
> try to modulate the _exclude_fs using kernel version numbers (which
> isn't guaranteed to work given the backporting possibility).

Sure, hardcoding a _notrun based on FSTYP is a last resort, and it would
definitely be better if we had a more elegant way to trigger the _notrun.
As a test suite, I cannot enforce or dictate what features a specific
filesystem must export just for the convenience of testing :)

> 
> This is a philosophical issue, and reasonable people could disagree on
> this approach.  For my part, I created /sys/fs/ext4/features/*
> precisely so that userspace (and fstests) so we can test if a
> particular feature is available on a particular kernel.  Otherwise, a
> test to see whether a particular feature "works" might have a false
> positive if the feature is broken, and the way we test whether the
> feature is present is basically what was accidentally broken with by a
> regression.

/sys/fs/$FSTYP/features/ is indeed incredibly helpful! Just a couple of
days ago, I was actually discussing expanding _require_fs_sysfs to support
features/ checks there, since our current checks are limited to the
/sys/fs/$FSTYP/$device/ directory:

https://lore.kernel.org/fstests/aloCfjjqesxpzL9z@zlang-mailbox/T/#mc5a0492cc00550467256951042828bef5d7fa38d

Thanks,
Zorro

> 
> Cheers,
> 
> 					- Ted
> 

Re: Should we consider disable generic/563 for file systems that do not support cgroup2?

[Christoph Hellwig]

On Mon, Jul 20, 2026 at 03:15:47AM +0800, Zorro Lang wrote:
> Sure, hardcoding a _notrun based on FSTYP is a last resort, and it would
> definitely be better if we had a more elegant way to trigger the _notrun.
> As a test suite, I cannot enforce or dictate what features a specific
> filesystem must export just for the convenience of testing :)

Yes.  And if we have to do that it should at least be in a common helper
and not sprinkled over the tests.

> /sys/fs/$FSTYP/features/ is indeed incredibly helpful! Just a couple of
> days ago, I was actually discussing expanding _require_fs_sysfs to support
> features/ checks there, since our current checks are limited to the
> /sys/fs/$FSTYP/$device/ directory:
> 
> https://lore.kernel.org/fstests/aloCfjjqesxpzL9z@zlang-mailbox/T/#mc5a0492cc00550467256951042828bef5d7fa38d

features can very much depend on the actual file system instance.
Trying to expose them globally doesn't make much sense.