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

["Theodore Tso" <tytso@mit.edu>]

On Tue, Sep 22, 2026 at 03:17:27PM -0500, Baokun Li wrote:
> 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.

What e2fsprogs's configure script will do is that it checks to see if
the blkid libraries are available for building against.  That is, if
you are using Debian or Ubuntu, you need to have the libblkid-dev
package install.  Among other things, this makes the following files
available:

/usr/include/blkid/blkid.h
/usr/lib/x86_64-linux-gnu/libblkid.a
/usr/lib/x86_64-linux-gnu/libblkid.so

... which are the files needed to build against libblkid and then link
against it statically or dynamically.  If these files aren't
available, then e2fsprogs will assume that it needs to build the local
libblkid, which is what is needed when building on Android, MacOS,
NetBSD, Open Solaris, etc.

> Rebuilding e2fsprogs with these options disabled made the test pass:
> 
>     ./configure --disable-libblkid --disable-fsck \
>             --disable-libuuid --disable-uuidd

This works, but this wll also disable those e2fsprogs features that
require those libraries.  So mke2fs will not generate UUID's in the
superblock, e2fsck won't handle LABEL=xyzzy specifiers, etc.
Fortunately xfstests don't depend on these featuers, so this will work.

The way I build with a locally patched e2fsprogs is that I'll build it
using the Debian build tools, which will enforce building with the
necessary prereqsuite packages, and then I'll put the built packages
in the directory test-appliance/debs and then build a fresh test
appliance image.  Or I'll just upload the packages to the VM and then
install it before launching the tests.

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

The patch to xfstests might still be appropriate, but it seems to me
that tune2fs should get fixed to update the device mtime (if it can),
and perhaps the kernel should try to update block device inode as well
as part of the FS_IOC_SETFSLABEL ioctl to address potential corner
cases with systemd/udev.

						- Ted