Pourquoi le programme `updatedb` s'exécute-t-il si vite?
Habituellement, lorsque j'ai des programmes qui effectuent une analyse complète du disque et parcourent tous les fichiers du système, leur exécution prend beaucoup de temps. Pourquoi updateb fonctionne-t-il si vite en comparaison?
La réponse dépend de la version de locate que vous utilisez, mais il y a de fortes chances que ce soit mlocate , dont updatedb s'exécute rapidement en évitant de faire analyses complètes du disque:
mlocate est une implémentation de localisation/mise à jourb. Le "m" signifie "fusion": updatedb réutilise la base de données existante pour éviter de relire la majeure partie du système de fichiers, ce qui accélère la mise à jourb et n'élimine pas autant les caches du système.
(La base de données stocke l’horodatage de chaque répertoire, ctime ou mtime, selon la date la plus récente.)
Comme la plupart des implémentations de updatedb, mlocate ignorera également les systèmes de fichiers et les chemins d'accès qu'il est configuré pour ignorer. Par défaut, il n'y en a pas dans le cas de mlocate, mais les distributions fournissent généralement un updatedb.conf De base qui ignore les systèmes de fichiers en réseau, les systèmes de fichiers virtuels, etc. (voir fichier de configuration de Debian pour exemple; c'est une pratique standard dans Debian, donc updatedb de GNU est configuré de la même façon ).
En plus de vérifier les heures de modification, mlocate ignore également certains sous-arbres du système de fichiers qui contiennent de nombreux fichiers inintéressants ou potentiellement dupliqués, comme spécifié dans /etc/updatedb.conf (et décrit dans man updatedb .conf ):
- Lier les montures
- Certains types de systèmes de fichiers (9p, afs, bdev, etc.)
- Bases de données du référentiel VCS (.git, .hg, etc.)
- Certains répertoires codés en dur (/ media,/tmp,/var/spool/cups, etc.).