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

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

On 2026/9/24 10:25, Theodore Tso wrote:
> 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

Right.  The flags went in only after the development packages were
installed.  The original hand build had no libblkid-dev, so it built
and installed the private copies, which is how the distro's
blkid/fsck/findfs got shadowed.

With libblkid-dev, uuid-dev and pkg-config installed, a plain
./configure now prints exactly your first output.  Compared with my
--disable build, the only extra program it produces is the fsck
wrapper.

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

Agreed -- checking whether a device is mounted on every probe might
cost more than simply re-probing the device.  Updating the mtime on
the write side (e.g., in tune2fs, xfs_io, or the kernel) looks like
the better approach.


Cheers,
Baokun