mlocate

#36 mlocate is confused by btrfs subvols and doesn't descend into all mount points
Opened by psychonaut. Modified

Open
Close Issue

The updatedb indexer of mlocate seems to be confused by btrfs subvolumes. It refuses to descend into them and to index them.

On my system, / is btrfs, with subvolumes for /opt, /usr/local, and so on. None of these directories get indexed by updatedb. Running updatedb with the --debug-pruning option shows that they are treated as bind paths which (according to the default settings in /etc/updatedb.conf) are pruned:

updatedb --debug-pruning

...
Skipping /opt': bind mount Skipping/usr/local': bind mount
...

This is almost certainly not what the user wants (and is not what happens with any other filesystem, AFAIK).

A temporary workaround is to disable pruning bind mounts in /etc/updatedb.conf, though the problem really needs to be fixed in mlocate itself I think.

Downstream reports:

Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746943
openSUSE: https://bugzilla.novell.com/show_bug.cgi?id=994663

Yeah.

More discussion is in https://bugzilla.redhat.com/show_bug.cgi?id=906591 and https://bugzilla.redhat.com/show_bug.cgi?id=723279 , so far there hasn’t been any idea much better than disabling PRUNE_BIND_MOUNTS I’m afraid.

Any update on this? Anything based on rpm-ostree, e.g. Fedora Core OS, Silverblue, I'd expect to run into this same problem because they make prolific use of bind mounts.

I posted the question to upstream Btrfs a couple years ago, and the path of least resistance is probably this reply:
https://lore.kernel.org/linux-btrfs/CAD=QJKgdiG7o8fayb=AXseUF6KDWsqk51Caua0nMiprvveG9yg@mail.gmail.com/

Although someone made a case that the old mlocate behavior worked on btrfs, and argues that switching to mountinfo is a regression.
https://lore.kernel.org/linux-btrfs/b5e7e64a-741c-baee-bc4d-cd51ca9b3a38@gmail.com/
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.