Написал glocate утилиту

http://www.git.stargrave.org/?p=glocate.git;a=summary
На фоне медленности поиска на HDD с 17.5M файлов и отсутствия быстрых
средств инкрементального обновления locate БД
(22b9eb13c837497c09b0d17e11cffac8aa655999), написал свою утилиту для
индексации файлов и их обновления. Пока жутко прежутко черновая версия,
но вроде работает как задумывал.

Сначала она пробегает по всей иерархии в текущей директории и составляет
отсортированные списки файлов с размерами и mtime-ом. Это хранит в виде
gob-файла (сериализация родная в Go) сжатого zstd. Для любого вывода
полностью загружает и декомпрессирует его в памяти.

Умеет выводить красивый вывод для человека (замена tree), типа:

    ├ music/HARTE/  №0 [283 GiB] 2022-05-10
    │ ├ 324-Boutoku_No_Taiyo/       №1 [33 MiB] 2020-12-10
    │ │ ├ 01.Silence_Before_Silver_Screen.mp3       №1 [3.7 MiB] 2016-10-13
    │ │ ├ 02.Quarter_Moon.mp3       №2 [1.6 MiB] 2016-10-13
    │ │ ├ 03.Red_Origin_Still_Streaming.mp3 №3 [2.0 MiB] 2016-10-13
    │ │ ├ 04.Plastic_Dream.mp3      №4 [2.9 MiB] 2016-10-13
    │ │ ├ 05.Japanese_Title.mp3     №5 [1.6 MiB] 2016-10-13
    │ │ ├ 06.Disgusting_Flower.mp3  №6 [2.4 MiB] 2016-10-13
    │ │ ├ 07.Swinging_Skull.mp3     №7 [1.3 MiB] 2016-10-13
    │ │ ├ 08.Broken_Clock.mp3       №8 [2.1 MiB] 2016-10-13
    │ │ ├ 09.Crawl_In_The_Transparency.mp3  №9 [1.6 MiB] 2016-10-13
    │ │ ├ 10.New_Demention.mp3      №10 [2.2 MiB] 2016-10-13
    │ │ ├ 11.Cobalt.mp3     №11 [1.9 MiB] 2016-10-13
    │ │ ├ 12.Flash_Rings_Link.mp3   №12 [2.6 MiB] 2016-10-13
    │ │ ├ 13.Moc.mp3        №13 [2.9 MiB] 2016-10-13
    │ │ └ 14.Glenghost.mp3  №14 [4.1 MiB] 2016-10-13
    │ ├ 7_H.Target-2011-Fast-Slow_Demolition/       №2 [293 MiB] 2020-09-06
    │ │ ├ 01.Transmutation_Energy_Machine.wv        №1 [17 MiB] 2020-09-06
    │ │ ├ 02.Technosex.wv   №2 [17 MiB] 2020-09-06
    │ │ ├ 03.Metal+Flesh.wv №3 [25 MiB] 2020-09-06
    │ │ ├ 04.Drill_Penis.wv №4 [18 MiB] 2020-09-06

вывод дружелюбный к парсингу компьютером:

    303730496828 2022-05-10 music/HARTE/
    34290985 2020-12-10 music/HARTE/324-Boutoku_No_Taiyo/
    3875800 2016-10-13 music/HARTE/324-Boutoku_No_Taiyo/01.Silence_Before_Silver_Screen.mp3
    [...]
    4292087 2016-10-13 music/HARTE/324-Boutoku_No_Taiyo/14.Glenghost.mp3
    306921714 2020-09-06 music/HARTE/7_H.Target-2011-Fast-Slow_Demolition/
    17598286 2020-09-06 music/HARTE/7_H.Target-2011-Fast-Slow_Demolition/01.Transmutation_Energy_Machine.wv
    18076892 2020-09-06 music/HARTE/7_H.Target-2011-Fast-Slow_Demolition/02.Technosex.wv

и просто вывод списка полных путей. Для всего этого можно указать
какой-то префикс, чтобы только часть иерархии показывалась. Именно это я
и сделал для вывода "тяжёлых" музыкальных альбомов своих.

Собственно, сам поиск утилита не делает: или суй в grep или fzf
какой-нибудь. Загружается этот файл в течении нескольких секунд.

Скорость создания БД -- упирается исключительно в IO у меня. Почти
столько же времени занимает что и просто сделать find по ФС. Вот правда
для 16TB раздела процесс под конец занимал почти 3.5GB. Загруженный в
память, при "штатном" использовании: отнимает 2GB. В общем то совсем не
мало, но я и не заморачивался экономией ресурсов и мне даже и так будет
удовлетворительно. БД для 17.5M файлов у меня заняла 128MB, что по моему
вполне себе терпимо. С ходу пришла мысль о том, что можно не хранить
размеры директорий: сжаться должно лучше, в надежде что это ни капли не
затормозит загрузку файла.

Ну и главная фишка: утилите можно скормить выхлоп zfs diff | sort -r и
все его действия (добавление, удаление, переименования, изменение) будут
применяться к загруженному состоянию, а дальше атомарно обновлено на
диске. Узнать какие изменения были произведены быстрее zfs diff-а всё
равно никто не сможет. zfs diff приятен тем, что его вывод,
отсортированный в обратном направлении, буквально говорит что и как надо
поочерёдно удалить и что обновить касательно mtime-а.