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

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

On Mon, Feb 09, 2026 at 02:50:00AM +0000, Shinichiro Kawasaki wrote:
> On Feb 06, 2026 / 09:38, Darrick J. Wong wrote:
> > 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. :/
> 
> Unfortunately, no. I made the change below in the test case, but I still see
> the "Health status has not beel collected" message.
> 
> diff --git a/tests/xfs/802 b/tests/xfs/802
> index fc4767a..77e09f8 100755
> --- a/tests/xfs/802
> +++ b/tests/xfs/802
> @@ -131,6 +131,8 @@ systemctl cat "$new_scruball_svc" >> $seqres.full
>  # Cycle mounts to clear all the incore CHECKED bits.
>  _scratch_cycle_mount
>  
> +_udev_wait $SCRATCH_DEV
> +
>  echo "Scrub Everything"
>  run_scrub_service "$new_scruball_svc"
>  
> 
> I also manually mounted the null_blk device with xfs, and ran "udevadm settle".
> Then still lsblk was failing to report fstype for the null_blk device (FYI, I
> use Fedora 43 to recreate the failure).

Waitaminute, how can you even format xfs on nullblk to run fstests?
Isn't that the bdev that silently discards everything written to it, and
returns zero on reads??

--D

> > 
> > > 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?
> 
> Yes, I agree that it will be the better solution since the test case will not be
> skipped even when there are other xfs filesystems mounted.