Что: 8e24a68248865cfcd58538871f8b96e6327376d8
Когда: 2022-07-15 00:15:38+03:00
Темы: go zfs
Написал 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-а.
Сгенерирован: SGBlog 0.34.0