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:
... Skipping /opt': bind mount Skipping/usr/local': bind mount ...
/opt': bind mount Skipping
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.
PRUNE_BIND_MOUNTS
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.