Re: [PATCH] formalize and fix disabling the RT subvolume

On Wed, Jul 01, 2026 at 12:54:07PM +0200, Christoph Hellwig wrote:
> On Tue, Jun 30, 2026 at 11:40:18AM -0700, Darrick J. Wong wrote:
> > On Tue, Jun 30, 2026 at 01:35:26PM +0200, Christoph Hellwig wrote:
> > > Various test unset SCRATCH_RTDEV to avoid dealing with metadata
> > > allocations for the RT subvolume in the main device or differences
> > > in RT subvolume behavior.  Besides being rather ad-hoc, this unset
> > > also fails to disable the internal RT zoned subvolume.
> > > 
> > > Add a _disable_scratch_realtime helper that not only unsets
> > > SCRATCH_RTDEV, but also disables the zoned allocator and with
> > > that the internal RT subvolume.
> > 
> > What if we want to run these tests on the internal rt volume?
> 
> Then we need to stop disabling the RT volume for them..

Ahaha ok with this patch applied, the regressions I see in generic/441
and xfs/656 go away.  generic/441 chokes because the scratch fs goes
down due to writeback error, so I assume it's ok to start excluding this
test.

xfs/656 is a different story:

--- /run/fstests/bin/tests/xfs/656.out	2026-03-13 16:19:08.152939212 -0700
+++ /run/fstests/logs/xfs/656.out.bad	2026-06-30 18:16:43.847849604 -0700
@@ -1,10 +1,9 @@
 QA output created by 656
 Format and mount
 pwrite: Input/output error
-pread: Input/output error
+stat: Input/output error
 pread: Input/output error
 fsync: Input/output error
 VICTIM pos NUM len NUM: directio_write: Input/output error
-VICTIM pos NUM len NUM: directio_read: Input/output error
 VICTIM pos NUM len NUM: buffered_read: Input/output error
 VICTIM pos NUM len NUM: buffered_write: Input/output error

I'm guessing that the write failure takes down the filesystem, which is
why the subsequent xfs_io pread can't even open the file.

Also the comment in xfs/655 and 656 doesn't make sense:

 # Disable the scratch rt device to avoid test failures relating to the
 # rt bitmap consuming all the free space in our small data device.
 unset SCRATCH_RTDEV

We're creating a regular sized data device, so this shouldn't be an
issue.

Eh, whatever, I'll clean up those two healer tests. :)
Reviewed-by: "Darrick J. Wong" <[email protected]>

--D