Re: [PATCH] generic/492: bypass the blkid cache when probing the label

[Baokun Li <libaokun@linux.alibaba.com>]

On 2026/9/22 11:43, Theodore Tso wrote:
> On Mon, Sep 21, 2026 at 04:49:10PM -0500, Darrick J. Wong wrote:
>>> The difference between the e2fsprogs and util-linux libblkid is the
>>> time granularity: the former stores seconds only (TIME="%ld",
>>> bid_time = time(0), compares st_mtime <= bid_time), while the latter
>>> stores usec (TIME="sec.usec") and has an nsec tie-break in the compare,
>>> so the same-second case is much easier to hit with the e2fsprogs blkid.
>> Perhaps xfstests-bld should use the system blkid then?  IIRC the one
>> in e2fsprogs is very old and out of date.
> Historically, xfstests-bld was built in environments where libblkid
> wasn't available.  This included Android's runtime (which uses the
> bionic libc), and grte (Google Runtime Environment)[1].
>
> [1] https://github.com/bazelment/lrte/blob/master/grte/grte-build
>
> However, as more and more tests require utilities from util-linux,
> xfstests-bld was taught to build util-linux.  And if util-linux is
> being built, then we don't use e2fsprogs-libs any more, which is where
> libblkid is built.  From build-all:
>
> if test -z "$USE_LOCAL_E2FSLIBS" -o -d util-linux; then
>     SKIP_E2FSLIBS=yes
> fi
>
> I've always built xfstesets-bld with util-linux, even though it is
> listed as an optional repository.  This is because (a) util-linux is
> needed for Android and other non-standard Linux environments, and (b)
> the version of util-linux used by earlier Debian Stable was too old
> for some of the newer tests in fstests and blktests.
>
> If you aren't building xfstests-bld with util-linux, it falls back to
> building libblkid from e2fsprogs-libs.  HOWEVER, we don't actually
> blkid, and libblkid is always built statically.  So what seems to be
> going on is that one of the programs built by xfstests-bld is using
> the older libblkid, and that results in the blkid cache being writen
> with a second granularity.
>
> I've never noticed this issue because I've always built with
> util-linux.  The way to solve this is to require building with the
> system libblkid if util-linux is not being built, and to drop
> e2fsprogs-libs from xfstests-bld.  Or just build xfstests-bld with
> util-linux.  :-)


Thanks for the detailed explanation.

I checked my environment again though -- it turned out not to be
xfstests-bld at all.  xfstests-bld never touches e2fsprogs.

What happened is that I had manually run "make install" of a locally
patched e2fsprogs in the test VM, which overwrote util-linux's blkid
and fsck.

Rebuilding e2fsprogs with these options disabled made the test pass:

    ./configure --disable-libblkid --disable-fsck \
            --disable-libuuid --disable-uuidd

I ran unpatched generic/492 60 times on each side in a VM: 12/60
failures with the hand-installed strays, 0/60 with util-linux's
blkid/fsck.

That said, I think the patch is still needed, because
FS_IOC_SETFSLABEL does not update the block device's mtime:

    blkid -s LABEL ...    # get A
    FS_IOC_SETFSLABEL     # set B (device mtime unchanged)
    blkid -s LABEL ...    # still get A (within 2s)

The first read writes a cache entry with TIME=now, and the ioctl
leaves the device mtime untouched, so a second read within the 2s
window still trusts the cache.

I reproduced this with util-linux 2.41.5 too, so
"blkid -c /dev/null" is what keeps the test deterministic
regardless of which blkid the image carries.


Cheers,
Baokun