Re: [bug report] xfs/802 failure due to mssing fstype report by lsblk

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Feb 06, 2026 at 08:40:07AM +0000, Shinichiro Kawasaki wrote:
> Hello Darrick,
> 
> Recently, my fstests run for null_blk (8GiB size) as SCRATCH_DEV failed at
> xfs/802 [3]. I took a look and observed following points:
> 
> 1) xfs_scrub_all command ran as expected. Even though SCRATCH_DEV is mounted,
>    it did not scrub SCRATCH_DEV. Hence the failure.
> 2) xfs_scrub_all uses lsblk command to list all mounted xfs filesystems [1].
>    However, lsblk command does not report that SCRATCH_DEV is mounted as xfs.
> 3) I leanred that lsblk command refers to udev database [2], and udev database
>    sometimes fails to update the filesystem information. This is the case for
>    the null_blk as SCRATCH_DEV on my test nodes.

Hrm.  I wonder if we're starting xfs_scrub_all too soon after the
_scratch_cycle_mount?  It's possible that if udev is running slowly,
it won't yet have poked blkid to update its cache, in which case lsblk
won't show it.

If you add _udev_wait after _scratch_cycle_mount, does the "Health
status has not beel collected" problem go away?  I couldn't reproduce
this specific problem on my test VMs, but the "udev hasn't caught up and
breaks fstests" pattern is very familiar. :/

> Based on these observations, I think there are two points to improve:
> 
> 1) I found "blkid -p" command reports that null_blk is mounted as xfs, even when
>    lsblk does not report it. I think xfs_scrub_all can be modified to use
>    "blkid -p" instead of lsblk to find out xfs filesystems mounted.
> 2) When there are other xfs filesystems on the test node than TEST_DEV or
>    SCRATCH_DEV, xfs_scrub_all changes the status of them. This does not sound
>    good to me since it affects system status out of the test targets block
>    devices. I think he test case can be improved to check that there is no other
>    xfs filesystems mounted other than TEST_DEV or SCRATCH_DEV/s. If not, the
>    test case should be skipped.

I wonder if a better solution would be to add to xfs_scrub_all a
--restrict $SCRATCH_MNT --restrict $TEST_DIR option so that it ignores
mounts that aren't under test?

--D

> At this moment, I don't have time to create patches for the improvements above.
> If anyone can work on them, it will be appreciated.
> 
> [1] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/tree/scrub/xfs_scrub_all.py.in#n55
> [2] https://unix.stackexchange.com/questions/642598/lsblk-file-system-type-not-appears-from-lsblk#642600
> 
> [3] xfs/802 failure console message
> 
> xfs/802            - output mismatch (see /home/shin/kts/kernel-test-suite/src/xfstests/results//xfs/802.out.bad)
>     --- tests/xfs/802.out       2026-02-04 20:44:52.254221182 +0900
>     +++ /home/shin/kts/kernel-test-suite/src/xfstests/results//xfs/802.out.bad  2026-02-06 17:04:24.336536185 +0900
>     @@ -2,4 +2,7 @@
>      Format and populate
>      Scrub Scratch FS
>      Scrub Everything
>     +Health status has not been collected for this filesystem.
>     +Please run xfs_scrub(8) to remedy this situation.
>     +cannot find evidence that /var/kts/scratch was scrubbed
>      Scrub Done
>     ...
>     (Run 'diff -u /home/shin/kts/kernel-test-suite/src/xfstests/tests/xfs/802.out /home/shin/kts/kernel-test-suite/src/xfstests/results//xfs/802.out.bad'  to see the entire diff)