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

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/

Login to comment on this ticket.

Metadata