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

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

On Sat, Feb 14, 2026 at 06:39:57AM +0000, Shinichiro Kawasaki wrote:
> On Feb 13, 2026 / 14:14, Darrick J. Wong wrote:
> [...]
> > Why doesn't udev record anything for
> > nullb0?  I suspect it has something to do with this hunk of
> > 60-block.rules:
> > 
> > ACTION!="remove", SUBSYSTEM=="block", \
> >   KERNEL=="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|vd*|xvd*|bcache*|cciss*|dasd*|ubd*|ubi*|scm*|pmem*|nbd*|zd*|rbd*|zram*|ublkb*", \
> >   OPTIONS+="watch"
> > 
> > This causes udev to establish an inotify watch on block devices.  When a
> > bdev is opened for write and closed, udev receives the inotify event and
> > synthesizes a change uevent.  Annoyingly, creating a new rule file with:
> > 
> > ACTION!="remove", SUBSYSTEM=="block", \
> >   KERNEL=="nullb*", \
> >   OPTIONS+="watch"
> > 
> > doesn't fix the problem, and I'm not familiar enough with the set of
> > udev rule files on a Debian 13 system to make any further diagnoses.  If
> > you're really interested in using nullblk as a ramdisk for this purpose
> > then I think you should file a bug against systemd to make lsblk work
> > properly for nullblk.
> 
> Darrick, thank you very much for digging it and sharing the interisting
> findings. Yes, it is really misterious why null_blk is not handled as other
> block devices. This motivated me to look into the udev rules, and I found that
> 60-persistent-storage.rules does this:
> 
> ...
> KERNEL!="loop*|mmcblk*[0-9]|msblk*[0-9]|mspblk*[0-9]|nvme*|sd*|sr*|vd*|xvd*|bcache*|cciss*|dasd*|ubd*|ubi*|scm*|pmem*|nbd*|zd*|rbd*|zram*|ublkb*", GOTO="persistent_storage_end"
> ...
> # probe filesystem metadata of disks
> KERNEL!="sr*|mmcblk[0-9]boot[0-9]", IMPORT{builtin}="blkid"
> ...
> LABEL="persistent_storage_end"
> 
> The "builtin-blkid" looks recording the block device attributes to the udev
> database. I added one more new rule file as follows on top of the rule file you
> added:
> 
> ACTION!="remove", SUBSYSTEM=="block", \
>   KERNEL=="nullb*", \
>   IMPORT{builtin}="blkid"
> 
> With this change, now lsblk reports that null_blk has xfs! I also confrimed that
> the test case xfs/802 passes.

Excellent!

> > > Anyway, I think blkid with --probe option is good for fstests usage, since it
> > > directly checks the superblock of the target block devices.
> > 
> > That's not an attractive option for fixing xfs/802.  The test fails
> > because xfs_scrub is never run against the scratch fs on the nullblk.
> > The scratch fs is not seen by xfs_scrub_all because lsblk doesn't see a
> > fstype for nullb0.  lsblk doesn't see that because (apparently) udev
> > doesn't touch nullb0.
> > 
> > The lsblk call is internal to xfs_scrub_all; it needs lsblk's json
> > output to find all mounted XFS filesystems on the system.  blkid doesn't
> > reveal anything about mount points.
> > 
> > Yes, we could change xfs_scrub_all to call blkid -p on every block
> > device for which lsblk doesn't find a fstype but does find a mountpoint,
> > but at that point I say xfs shouldn't be working around bugs in udev
> > that concern an ephemeral block device.
> 
> Thanks for the explanation. My take away is that systemd/udevd support is the
> prerequisite of fstests target block devices. I suggested blkid -p because I
> assumed that fstests would be independent from systemd/udevd. But the assumption
> was wrong.
> 
> My next action is to set up the udev rules for null_blk in my test environments.
> Thank you again for your effort.

If you decide to send a PR to systemd to fix the udev rules upstream,
please cc me if they push back.  Thanks for your persistence!

--D