Алгоритмы сжатия/распаковки

[sfs]

ZSTD v1.4.10 из pf-kernel.

Эта версия в pf ядре начиная с версии 5.11-pf6, т.е. у нас давно такая
В очередной раз убеждаюсь : не разбираешься в свежих фичах ядра - компили свежий pf - там все есть

Для дистров надо просто обновить . Ок - потихоньку обновлю

[sfs]

перепаковываю в lzo  ( если не забываю ), разница ощутима без замеров, но не так чтоб прям машину подменили

Подобное замечал только на твбоксах (4 arm ядра по 1,8ггц). Там перепаковал в zstd. Тоже на ощущениях. Получается- связано с частотой проца
На x86_64 CPU~Dual core Intel Celeron G540 (-MCP-) speed/max~2442/2500 MHz проблемы не ощущаю
Тестов для аргументации не придумал. Хотя можно попробовать замерять загрузку системы или первый запуск тяжелой проги (при втором и более уже прокэшируется)
Никто так не тестировал?

[betcher]

В магос есть скрипт для тестов алгоритма сжатия. Сравнивает скорость чтения файлов. Попробуйте себе модифицировать.
https://github.com/magos-linux/magos-linux/blob/master/make_MagOS/files/patches/rootfs/MagOS/usr/lib/magos/scripts/squashtest

[sfs]

скрипт для тестов алгоритма сжатия

Думаю - это не совсем то. Какой алгоритм быстрее и так понятно. Но при реальной работе происходит кэширование и загрузка в память. Поэтому алгоритм сжатия реально повлияет только на скорость первой загрузки проги

[betcher]

В том и дело что не понятно. Потому, что зависеть будет от скорости чтения с носителя и скорости распаковки, то есть в итоге алгоритм в идеале подбирается под железо.
Влияет естественно только на первый запуск, пока не прокэшировалось, а значит и на скорость запуска ОС тоже.

[krasnyh]

Влияет естественно только на первый запуск, пока не прокэшировалось

Когда-то давно, обсуждалось сравнение больших монолитов MagOS и маленьких модулей PRA (не могу найти это обсуждение). И в ответ, от разрабов MagOS, была высказана мысль, что размер ничего не решает, т.к. в этом самом огромном монолите распаковываются/читаются на лету только нужные данные.

И значит, в моем понимании, скорость чтения (определенная алгоритмом сжатия/распаковки) влияет не только на первый запуск, ведь обращение будет к разным данным в разный период времени, т.е. постоянное частое обращение к монолиту, а значит и постоянная частичная распаковка на лету и чтение. И значит быстрый алгоритм скажется не только в случае описанном в цитате сверху.


Надеюсь я смог правильно донести, то что читал на страницах здешних обсуждений и свое понимание.

[krasnyh]

В дополнение к посту, ссылка на Бенчмарк, https://forum.puppyrus.org/index.php?topic=23501.msg179719#msg179719

[sfs]

Влияет естественно только на первый запуск, пока не прокэшировалось, а значит и на скорость запуска ОС тоже.

Да. Т.к. запуск ОС = певвый запуск некоторого кол-ва прог

размер ничего не решает

Если не использовать copy2ram, который что-то даст только на совсем мертвых носителях.
Ну и кроме того в раздутом , универсальном софте  куча дополнительных зависимостей, которые могут запускать демонов и загружать в память  не нужные юзеру либы раздувается ресурсоемкость. В том числе и скорость чтения, т.к. прочитать надо больше. Поэтому оптимизация софта перекомпиляцией - один из главных методов получения "маленькой и быстрой" ОС.

скорость чтения (определенная алгоритмом сжатия/распаковки) влияет не только на первый запуск, ведь обращение будет к разным данным в разный период времени, т.е. постоянное частое обращение к монолиту

Когда в модуле одна прога - при старте она вместе со всеми нужными ей либами загружается в память и далее , как правило работает со своим профилем и конфигами, т.е. из своего модуля больше ничего не читает. Кстати - профиль (например браузера) будет быстрее работать в памяти. Т.е. сохраненка на медленном носителе - зло. В армбиан даже специально закостылили скрипт переноса профиля браузера в tmpfs и обратно (при выключении)
Поэтому в память есть смысл загружать только базу , в которой куча либ, используемых прочим софтом, который многократно загружается - выгружается
Я так понимаю работу фругала

[krasnyh]

Жму папку 23мб
time mksquashfs 035-gtk2-1811-sf03.pfs  035-gtk2-1811-sf03.pfs .xz.pfs -b 512k -comp xz -Xbcj x86
real   0m6,954s

du 035-gtk2-1811-sf03.xz.pfs
4172   035-gtk2-1811-sf03.xz.pfs

time unsquashfs 035-gtk2-1811-sf03.xz.pfs
real   0m0,254s
--------------
time mksquashfs 035-gtk2-1811-sf03.pfs  035-gtk2-1811-sf03.pfs .xz.pfs -b 512k -comp zstd -Xcompression-level 22
real   0m7,876s

4564   035-gtk2-1811-sf03.pfs.zs.pfs

time unsquashfs 035-gtk2-1811-sf03.pfs.zs.pfs
real   0m0,067s

Т.е. при примерно одинаковом времени сжатия и размере pfs - zs в 3 раза быстрее распаковывается
Пакуем 1 раз. распаковка - постоянно
Получается надо переходить на zs....

Взял модуль 01-drivers.xzm (317M) из MagOS, как самый большой из возможных во всех сборках.
Монтировал и сжимал (mksquashfs) в /tmp с алгоритмами xz (-b 512k -Xbcj x86), zstd (-b 512K -X 22; -b 1M -X 22), а так же дефолтным mkdwarfs.

Понятно, что xz дал те же 317M, zstd - около 350M (-b 512k) и 334M (-b 1M). Mkdwarfs - 266M.


Теперь распаковка с unsquashfs и dwarfsextract для dwarfs.
Для xz - 10 c
zstd (-b 1M) - 7 c
zstd (-b 512k) - 1,722 c
dwarfs - 1,965 c


Резюме. Лучшие значения у squashfs с zstd (-b 512k), но размер 350M против 317M у xz. Dwarfs же, при размере 266M, распаковывает за 1,965 c, но процесс сжатия растянут во времени в силу длительного процесса сканирования.


upd.

длительного процесса сканирования

Нормально, если обеспечить достойную скорость чтения:
1,193,331,977  99%  538.59MB/s

[krasnyh]

Перепаковал себе систему в zstd, потестирую, посмотрю.

Код

$ cat /etc/pfs.cfg 
compression="-b 512K -comp zstd -Xcompression-level 18"

Пример скрипта перепаковки, без учета подмодулей.
Пробовал выдрать куски из pfsrebuild, но там черт ногу сломает. Да и подумал, для пользователя нет никакой нужды в этих субмодулях, если только для удобства разработчика, при добавлении/удалении пакетов. Но, если разрабы оптимизируют упомянутый скрипт, хуже не будет, думаю. )


Что заметил уже.
- У меня нет рабочего стола и меню опенбокса по ПКМ теперь быстрее прорисовывается/перечитывается, раньше была ощутимая задержка.
- Быстрее запускается второе окно mpv, к уже воспроизводящему видео/аудио первому.
- Быстрее читается папка /usr/bin, там около 2000 файлов.
- Так же осознал, что gtk3 приложения тормозные и им ничем не поможешь. Наглядный пример spacefm, как не убыстряй чтение, он всегда будет запускаться с небольшой задержкой, и первый раз и второй и десятый.... Так же transmission-gtk. При этом AzPainter вылетает как чертик из табакерки. ) Я не говорю что это хорошо и должно быть для всех приложений, но это пример.

Такие вот несколько мелочей, для начала.
И да, у меня из prar2103/de-ovs взята только /base, остальное доустановил в монолит по списку своих пакетов:

Код

$ sudo pacman2pfs $(cat /mnt/sda3/мои_пакеты_pfs-test.txt)

Код

$ inxi -C
CPU:       Quad core Intel Xeon E5450 (-MT-MCP-) cache: 6144 KB
           clock speeds: max: 2997 MHz 1: 1998 MHz 2: 2098 MHz 3: 1998 MHz 4: 1998 MHz

p.s. Сначала пробовал -b 1M -comp zstd -Xcompression-level 22, он не настолько разрастается в размере, но по быстродействию показалось, что это близко к xz.

Помимо этой темы, алгоритмы еще обсуждались в mkpfs сжатие. И здесь Changes/OptimizeSquash, там хорошие скрины.

p.s.2. Ну и повторюсь по поводу dwarfs, который zstd, но жмет в меньший размер, чем xz. Раньше я выражал неудовольствие медленным сканированием, но если поместить папку в /tmp или ~/live, то пролетает быстрее молнии. )

[krasnyh]

Пример скрипта перепаковки, без учета подмодулей.

Был неправ, все же mkpfs считывает инфу о подмодулях.

Код

live@roll2103 % pfsinfo 000-kernel-5.13.0-pf5-lf5_64.pfs 
cryptsetup-static-1.4.3-1-any
linux-pf-generic-5.13.5-4-x86_64
linux-pf-preset-default-5.11.0.pf2-1-x86_64
uksmd-git-0.0.0.r19.b6af35c-1-x86_64
z-kern

live@roll2103 % unsquashfs -s 000-kernel-5.13.0-pf5-lf5_64.pfs | grep -E 'zstd|compression'
Compression zstd
	compression-level 18

upd. Просто привык, что в гуи pfs-mk, если не выбрать "Склеить", то соберет в монолит. А тут получается, что консольный вариант справился без всяких доп. ключей.
Или сыграло, что в качестве исходной папки используется bundles. Но я не знал о таком замечательном эффекте. )

[sfs]

Подобное замечал только на твбоксах

Перепаковал https://mirror.yandex.ru/puppyrus/puppyrus-a64/pfs-portable/google-chrome-gtk3-p-95.0.4638.69_64-au02.pfs , который уж совсем долго загружался при старте системы. Скорость его первого запуска увеличилась многократно.
Тогда перепаковал и https://mirror.yandex.ru/puppyrus/roll/2110/pfs/001-prar-2110-sf05.pfs так

-b 512K -comp zstd -Xcompression-level 18

Скорость загрузки увеличилась в 2 раза. Проверил на двух ПК : 2 ядерном celeron и 4я i5 (т.е. ускорение заметно на любом проце)
Попробовал и copy2ram - на ssd ничего не дало.

Выводы : базу и толстые проги типа браузеров, DEVX , офиса и т.п. актуально перепаковать в zstd. Размер модуля увеличивается некритично
Для copy2ram размер критичен, но сам  copy2ram на hdd ssd не актуален
Маленькие модули с простыми прогами особого смысла перепаковывать нет, т.к. первый раз и так быстро запускаются
Напомню , что при следующих запусках ускорения уже нет (т.е. и так быстро за счет кэша, не зависимо от типа компрессии)
Прошу всех протестировать и будем определяться в каких дистрах что пережать и с какими параметрами

Посмотреть тип модуля : unsquashfs -s ваш.pfs | grep ompression
Перепаковать - скриптом из аттача

[sfs]

grep ompression

Именно grep ompression или grep -i Compression иначе уровень сжатия не увидишь

[k0l0p0k]

grep ompression

Именно grep ompression или grep -i Compression иначе уровень сжатия не увидишь

grep ompression выдавал пустую строку,
поэтому усомнился в правильности

[sfs]

grep ompression выдавал пустую строку,

ничего не путаете? На каком модуле?