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

[Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>]

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.


> > 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.