Das war nicht das Problem, aber gerade beim Aktualisieren der Datenbank dachte ich schon, ich hätte die Ursache gefunden.
updatedb(.mlocate) wird standardmäßig einmal pro Tag von mlocate.service ohne weitere Optionen und als root aufgerufen. Rufe ich updatedb aber selbst auf, gibt es plötzlich viel mehr Dateien und Verzeichnisse in der Datenbank
Code: Alles auswählen
# systemctl start mlocate.service
# locate --statistics
Database /var/lib/mlocate/mlocate.db:
396 directories
7442 files
287163 bytes in file names
177619 bytes used to store database
Code: Alles auswählen
# updatedb.mlocate
# locate --statistics
Database /var/lib/mlocate/mlocate.db:
14029 directories
157467 files
8623341 bytes in file names
3604903 bytes used to store database
Das dürfte an einigen systemd-Optionen in der »
/lib/systemd/system/mlocate.service« liegen (PrivateTmp, PrivateDevices, Private...), die dafür sorgen, dass updatedb in eigenen Namespaces läuft, aber wie es gleich 20 bis 40 Mal so vielen Dateien und Verzeichnisse sein können ist mir nicht klar und das obwohl die Dateien, die ich gerne finden würde, immer noch nicht dabei sind.
(Insgesamt sind auf diesem Dateisystem etwa 10^5 Verzeichnisse und 10^6 Dateien – keine Ahnung was hier vorgeht.)
Die Option
in der »
/etc/updatedb.conf« dürfte die eigentliche Ursache meines Problems sein. Offensichtlich werden btrfs-subvolumes ab dem zweiten gemounteten Volume pro Dateisystem gleich behandelt wie bind-mounts.
Setze ich die Option auf "no" findet updatedb alle Dateien, allerdings in mehrfacher Ausführung, weil ich auch das root-volume von btrfs gemountet habe (aber das kann ich ja anhand des Pfads vom Indexieren ausschließen – hoffe ich zumindest).
Danke für die Denkanstöße, das Problem ist damit gelöst.