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

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

On Wed, Sep 23, 2026 at 06:02:38PM -0500, Baokun Li wrote:
> >>     ./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.
> 
> Hmm, what I disabled is exactly the set duplicated by util-linux:
> the blkid/uuid libs and UUID/LABEL= handling all live there, so
> the tools just link the system ones -- there is no functional loss.

The fact that you needed the --disable options implies that e2fsprogs
wasn't able to use the util-linux supplied libraries.  If the
configure script determines libblkid and libuuid are available for
linking against, (e.g., libblkid-dev and uuid-dev are installed), the
built-in libblkid and libuuid file systems are disabled.

From the configure script output:

checking for blkid_get_cache in -lblkid... yes
Using system blkid library by default

checking for uuid_generate in -luuid... yes
Using system uuid by default
Disabling uuidd by default

In contrast, if you run the configure script on MacOS, NetBSD, or a
Linux system missing the libuuid / libblkid development files, you
will see:

checking for uuid_generate in -luuid... no
Enabling private uuid library by default
Building uuidd by default

> Also, a thought that just came up: on the blkid side, would it be
> feasible to not trust the cache for mounted devices and always
> re-probe?  The mount / set label / umount / get label (within 2s)
> window would remain, but it would be much smaller.

Maybe.  It's not clear how often people might be trying to query the
blkid data.  Also, figuring out whether or not a device is mounted is
not free.  That would mean that for every blkid query, it would have
to read /proc/mounts to make that determination.  And note that on
some data center servers, there could potentially be hundreds if not
thousands of entries in /proc/mounts, either because you have a huge
number of bind mounts or overlayfs, and/or because you might have a
huge number of read-only iscsi mounts to deliver software packages to
your container based Borg or Kubernetes jobs.

I suppose you could put in the blkid cache a hint as to whether the
file system is mounted, but that in itself could get stale and out of
date.

Cheers,

					- Ted