Почему программа `updatedb` работает так быстро?

Обычно, когда у меня есть программы, которые выполняют полное сканирование диска и просматривают все файлы в системе, они запускаются очень долго. Почему updatedb работает так быстро по сравнению?

performance updatedb

— hugomg
источник

Ответы:

Ответ зависит от версии locateвы используете, но есть шанс , что это mlocate, чей updatedbбежит быстро, избегая делать полное сканирование диска:

mlocate является реализацией locate / updatedb. «M» означает «объединение»: updatedb повторно использует существующую базу данных, чтобы избежать перечитывания большей части файловой системы, что делает updatedb быстрее и не перегружает системный кэш.

(В базе данных хранится метка времени каждого каталога, ctimeили mtime, в зависимости от того, что новее.)

Как и большинство реализаций updatedb, mlocate's' также пропускает файловые системы и пути, которые он настроил игнорировать. По умолчанию нет ни в mlocateслучае «S, но дистрибутивы обычно обеспечивают основной , updatedb.confкоторый игнорирует сетевые файловые системы, виртуальные файловые системы и т.д. (см файл конфигурации в Debian , например, это является стандартной практикой в Debian, так ГНУ updatedbбудет выполнено аналогично ).

— Стивен Китт
источник

Довольно неплохой вопрос и ответ, даже не знал, что были «разностные» сканирования.

— Руи Ф Рибейро

Благодарность! Я никогда не замечал, что изменение файла также изменяет ctime и mtime всех его родительских каталогов.

— hugomg

@ Hugomg Я не думаю, что это действительно так. Это должно только изменить mtimeего непосредственного родителя.

— Кусалананда

Так что, если я правильно понимаю, mlocateзаботится о ctimeи mtimeчто означает , что заботится только о том списка записей каталога по - прежнему те же (не удалены или добавлены файлы), что означает , что не заботится о фактических самих файлов. Это верно ?

— Сергей Колодяжный

@ Сергей: Конечно. locateне grep -R. Он не читает содержимое файла.

— Кевин

В дополнение к проверке времени модификации, mlocateтакже игнорируются некоторые поддеревья файловой системы, которые имеют много неинтересных или потенциально дублирующих файлов, как указано в /etc/updatedb.conf (и описано в man updatedb.conf ):

Привязные крепления
Некоторые виды файловых систем (9p, afs, bdev и т. Д.)
Базы данных хранилища VCS (.git, .hg и т. Д.)
Некоторые жестко закодированные каталоги (/ media, / tmp, / var / spool / cups и т. Д.).

— hugomg
источник

По умолчанию это не так, поэтому базовое поведение зависит от используемого дистрибутива. (Другие updatedbреализации также поддерживают настроенные исключения.)

— Стивен Китт

Верно. Я описывал значения по умолчанию для Fedora.

— hugomg