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 06:00:40PM -0800, Darrick J. Wong wrote:
> On Mon, Feb 09, 2026 at 07:54:38AM +0000, Shinichiro Kawasaki wrote:
> > On Feb 09, 2026 / 07:28, hch wrote:
> > > On Sun, Feb 08, 2026 at 10:07:16PM -0800, Darrick J. Wong wrote:
> > > > 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??
> > > 
> > > nullblk can be used with or without a backing store.  In the former
> > > case it will not always return zeroes on reads obviously.
> > 
> > Yes, null_blk has the "memory_backed" parameter. When 1 is set to this, data
> > written to the null_blk device is kept and read back. I create two 8GiB null_blk
> > devices enabling this memory_backed option, and use them as TEST_DEV and
> > SCRATCH_DEV for the regular xfs test runs.
> 
> Huh, ok.  Just out of curiosity, does blkid (in cache mode) /ever/ see
> the xfs filesystem?  I'm wondering if there's a race, a slow utility, or
> if whatever builds the blkid cache sees that it's nullblk and ignores
> it?

Ah, I see.  The problem isnt *blkid* failing to see the new xfs
filesystem, it's lsblk failing to see that it has an xfs filesystem:

# udevadm monitor &
[1] 5743
# monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent


# mkfs.xfs -f /dev/nullb0
meta-data=/dev/nullb0            isize=512    agcount=4, agsize=65536 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
         =                       exchange=1   metadir=0
data     =                       bsize=4096   blocks=262144, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
         =                       rgcount=0    rgsize=0 extents
         =                       zoned=0      start=0 reserved=0
Discarding blocks...Done.
#
<taps foot>
# mkfs.xfs -f /dev/sda
meta-data=/dev/sda               isize=512    agcount=4, agsize=314368 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
         =                       exchange=1   metadir=0
data     =                       bsize=4096   blocks=1257472, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
         =                       rgcount=0    rgsize=0 extents
         =                       zoned=0      start=0 reserved=0
Discarding blocks...Done.
# KERNEL[1500.715783] change   /devices/pci0000:00/0000:00:06.0/virtio2/host0/target0:0:0/0:0:0:0/block/sda (block)
UDEV  [1500.806556] change   /devices/pci0000:00/0000:00:06.0/virtio2/host0/target0:0:0/0:0:0:0/block/sda (block)

So for some reason nullb0 doesn't generate kernel uevents when mkfs.xfs
closes the block device, like it does for scsi disks.  I don't know why
that is, but I'll look at it when I get a chance; it's very late here
now.

--D