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

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

On Feb 09, 2026 / 18:00, 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?

I tried the experement below, using /dev/nullb1 formatted as xfs:

# Clear blkid cache
$ sudo rm /run/blkid/blkid.tab

# Call blkid, but normal user can not parse superblock, then can not get fstype.
$ blkid --match-tag=TYPE /dev/nullb1

# Call blkid with superuser privilege. It can get fstype, but does not cache it,
# since --probe option is specified.
$ sudo blkid --probe --match-tag=TYPE /dev/nullb1
/dev/nullb1: TYPE="xfs"

# Still normal user can not get fstype since fstype is not cached.
$ blkid --match-tag=TYPE /dev/nullb1

# Call blkid as superuser without --probe option. It caches the fstype.
$sudo blkid --match-tag=TYPE /dev/nullb1
/dev/nullb1: TYPE="xfs"

# Now normal user can get fstype referring to the cache
$ blkid --match-tag=TYPE /dev/nullb1
/dev/nullb1: TYPE="xfs"


Based on this result, my understanding is that blkid caches its superblock
parse results when --probe, or -p option, is not specified. As far as I git
grep util-linux, this behavior does not change for null_blk.

Anyway, I think blkid with --probe option is good for fstests usage, since it
directly checks the superblock of the target block devices.