LINUX.ORG.RU
ФорумTalks

Как лучше сжимать initramfs. Серия тестов.

 , ,


0

2

Пока идут обсуждения о включении zstd в ядро, можно потестить размер получаемых образов и сделать некоторые выводы. Просто оставлю это здесь, возможно кому-то окажется полезным, когда встанет вопрос о создании загрузочного дистрибутива.

В качестве «эталона» возьмём Gentoo. Скачиваем stage3 amd64, распаковываем, размер дистрибутива:

# du -sh gentoo/
1.1G	gentoo/
# du -s gentoo/
1104960	gentoo/

plain = 1.1G

Простейший initramfs, используя саму директорию Gentoo для создания образа.

Для работоспособности нужно только сделать симлинк ln -s sbin/init init.

Это просто cpio без всякого сжатия.

# mkinitramfs gentoo/ > initrd 
1938832 blocks
# du -sh initrd
947M	initrd
# du -s initrd
969420	initrd

cpio = 947M

В том же режиме «standalone» директории упакуем в gzip.

# mkinitramfs gentoo/ | gzip -c -9 -v > initrd.gz
1938832 blocks
 67.1%
# du -sh initrd.gz 
312M	initrd.gz
# du -s initrd.gz 
318628	initrd.gz

gzip = 312M

xz, самый распространённый из самых «сильных» форматов сжатия на данный момент.

# mkinitramfs gentoo/ | xz -c -C "crc32" -T 0 -9 -e -v > initrd.xz
1938832 blocks
  100 %       167.3 MiB / 946.7 MiB = 0.177   8.6 MiB/s       1:49             
# du -hs initrd.xz
168M	initrd.xz
# du -s initrd.xz
171308	initrd.xz

xz = 168M

Теперь взглянем на современный, инновационный, сногшибательный, духозахватывающий, неповторимый zstd!

# mkinitramfs gentoo/ | zstd -T0 --ultra -100500 -v - > initrd.zst
Note: 8 physical core(s) detected
Warning : compression level higher than max, reduced to 22 
(L22) Buffered : 932 MB - Consumed :   2 MB - Compressed :   0 MB => 33.15%   
# du -sh initrd.zst 
173M	initrd.zst
# du -s initrd.zst 
176432	initrd.zst

zstd = 173M

А разговоров то было.... Ну, справедливости ради стоит отметить, сильная его сторона вовсе не в возможностях сжатия, а в скорости распаковки. Условную планку «xz» по уровню сжатия пока ещё не преодолели.

Теперь давайте взглянем на альтернативный метод предоставления системы из initramfs, как «слой» с использованием SquashFS с сохранием данных в tmpfs.

# mkinitramfs `mktemp -d` --overlay gentoo --squashfs-xz --output $PWD/initrd.squashfs.xz
Parallel mksquashfs: Using 16 processors
Creating 4.0 filesystem on /tmp/tmp.scQzUt6MLO/overlays/10-gentoo, block size 1048576.
[============================================================] 53192/53192 100%
# du -sh initrd.squashfs.xz 
217M	initrd.squashfs.xz
# du -s initrd.squashfs.xz 
221292	initrd.squashfs.xz

squashfs.xz = 217M

Вот это да, initramfs с системой упакованной в squashfs + xz получился немногим больше чем просто initramfs + xz.

Какие из этого можно сделать выводы?

  • Если вы ограничены в объёме RAM, но хотите работать в tmpfs, тогда используйте squashfs + xz или squashfs + zstd.

# mkinitramfs `mktemp -d` --overlay chroot --output $PWD/initrd --squashfs-xz

  • Если выделить пару-тройку GB под систему не проблема, тогда используйте overlay без squashfs, и будет вам уютный tmpfs без глюков самого overlayfs.

# mkinitramfs `mktemp -d` --overlay chroot --output $PWD/initrd

Специальный приглашённый гость: mkinitramfs из пакета ( https://github.com/sp00f1ng/boobstrap ).

А всё это, как водится, реклама. А на сегодня всё. До новых встреч. :-) :-|

★★★★★

Ответ на: комментарий от pekmop1024

Исправляюсь ))

# mkinitramfs gentoo/ | lz4 -c -9 -v > initrd.lz4
Read : 940 MB   ==> 37.32%   1938832 blocks
Compressed 992681984 bytes into 370076172 bytes ==> 37.28%                     
# du -sh initrd.lz4 
353M	initrd.lz4
# du -s initrd.lz4 
361404	initrd.lz4

lz4 = 353M

Spoofing ★★★★★ ()

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

lz4 — самое быстрое сжатие;

zstd — самая быстрая распаковка;

xz — самое сильное сжатие.

SquashFS — вообще файловая система со всеми вытекающими, отсюда и размер.

Могу ошибаться, поправьте если что не так.

Spoofing ★★★★★ ()
Последнее исправление: Spoofing (всего исправлений: 2)
Ответ на: комментарий от Spoofing

lz4, вроде как, самый быстрый по всем пунктам. Но жмет не особо.

pekmop1024 ★★★★★ ()
Ответ на: комментарий от pekmop1024

Лучше бы им многоядерность прикрутили. По факту с открытым htop я не увидел, чтобы архиваторы насиловали процессор.

gzip, с ним всё понятно, земля пухом.

xz больше 4х потоков не использовал вообще за всё время, даже при явном указании -T 16

zstd, не увидел, чтобы он хоть что-то вообще использовал.

И только SquashFS заставил процессор долбиться в соточку с небольшой передышкой где-то на 40%, видимо что-то иное делает с данными.

Spoofing ★★★★★ ()

…когда угадал автора темы по заголовку.

AX ★★★★★ ()
Ответ на: комментарий от Spoofing

gzip, с ним всё понятно, земля пухом.

думается, что когда тебя повезут в крематорий, gzip ещё будет вовсю использоваться. простые и надёжные решения живут очень долго.

vtVitus ★★★★★ ()
Ответ на: комментарий от vtVitus

Разве gzip используют не из-за вендорлока и легаси? Где могли - уже викинули на свалку истории.

RazrFalcon ★★★★★ ()
Ответ на: комментарий от RazrFalcon

без разницы где используется gzip, важно что он используется и будет использоваться ещё очень и очень долго и уж точно переживёт xz, zstd и т.п. При открытии этой станицы в браузере он заюзан и, наверное, не раз.

vtVitus ★★★★★ ()

boobs trap

Жениться тебе, барин, надо

ya-betmen ★★★★★ ()

Добавь лицензию в репу, а то сейчас по факту это не свободный софт.

Difrex ★★★★ ()

Не работает твой скрипт. Ща тебе баг открою.

Difrex ★★★★ ()
Ответ на: комментарий от Difrex

спасибо, я исправлю это сейчас. ещё не исправил ))

Spoofing ★★★★★ ()
Ответ на: комментарий от Difrex

спасибо что пинаете меня и заставляете доводить проект до ума )) самое главное чтобы три ключевых утилиты работали у каждого, а потом уже можно будет фичи вводить.

сейчас уже подумываю сделать import/export чрут директорий, т.е. установил чрут, можешь сделать export и оно сохранится в tar-архиве, потом этот архив можешь распаковать через import и продолжить работать с ним.

и сделать внутренний интерфейс с командами, например все tar архивы с образами сохраняем где-нибудь. а дальше берём и пишем скрипт

# указываем мейнтейнера скрипта
DOMINANT name <e-mail>

# указываем tar архив с которым будем работать
MASTER ubuntu

# указываем куда сохраним результат работы
SLAVE /var/ftp/default.iso

# указываем рабочую директорию
ROOM $(mktemp -d -p $PWD)

# выполняем команды
DO sed -i "s/SERVICES=.*/SERVICES=(lo net crond sshd)/g" $DIR/etc/rc.conf

PLUG $HOME/.ssh/id_rsa.pub=$DIR/root/.ssh/authorized_keys

PLUG $PWD/autorun.sh=$DIR/etc/rc.local

# сохраняем готовый iso
COME

ну как? нормально? :)

Spoofing ★★★★★ ()

Учитывая, что принципиальной разницы в размере между zstd и xz нет, а zstd быстрее, выбор очевиден.

Спасибо, Facebook.

commagray ★★★★★ ()
Ответ на: комментарий от Spoofing

да, при распаковке отсутствие многоядерности сильно подбешивает.
будто в начало 90ых попал.

darkenshvein ★★★★★ ()
Ответ на: комментарий от commagray

Действительно, zstd быстрее, в интернетах озвучивали цифры аж в 1300%, правда не помню с чем сравнивали, но не суть. Хотелось бы чтоб поскорее это включили в ядро, чтоб можно было по-человечески initrd распаковать.

С пацанами тут решаем, чтобы через PXE загружать минимальный образ в initrd размером метров 50, а он уже запускает торренто-качалку и по p2p будет подтягивать нормальный полноценный образ, и далее kexec'аться в него. И всё это в tmpfs. Такие дела.

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

Хотелось бы чтоб поскорее это включили в ядро, чтоб можно было по-человечески initrd распаковать.

Я вписал COMPRESSION=zstd в mkinitcpio.conf на своём Arch. Вроде, работает. 🤷

commagray ★★★★★ ()
Ответ на: комментарий от Spoofing

минимальный образ в initrd размером метров 50

емнип раза в 1.5 точно меньше может быть.

а он уже запускает торренто-качалку

а какие кандидаты качалочек? когда-то удалось полностью статически собрать aria2 (aria2c), у неё как раз можно скриптятину навесить на события завершения скачки торрента и прочие. может есть что-то меньше и лучше на примете?

n_play ()
Ответ на: комментарий от pekmop1024

Есть lz4-hc, ассиметричный, который жмёт посильнее. Но вообще я радикально не понимают топикастера. lz4 создавался как архиватор «работающий со скоростью memcmp», т.е. с упором на скорость и внезапно он показывает результат сопоставимый с gzip. zsdt, который делался как усиленный вариант lz4 медленнее, но с более сильным сжатием уже приближается к xz, обгоняя gzip, а ему чего-то не нравится.

atrus ★★★★★ ()
Ответ на: комментарий от pekmop1024

Вот сейчас проверил, у меня zstd выдал initrd заметно меньше, чем lz4 (fallback.img ~40 мегабайт против ~60 соответственно).

Не сказал бы, что от этого есть какая-то разница принципиально, но zstd уже мейнстрим (pacman, btrfs, f2fs) и не грех его подцепить. x3

commagray ★★★★★ ()

Spoofing прости я в прошлой теме не отписывался поэтому делаю в этой. Вот так я велосипедил initramfs когда была такая потребность.

init_6 ★★★★★ ()
Ответ на: комментарий от n_play

transmission. вот такую сборку запилил: https://github.com/sp00f1ng/boobstrap/blob/5aa2d8de005284f0a05fc11dbd5b811e82...

идея в том, чтобы на уровне /etc/rc.local сразу после загрузки системы:

1. узнать IP шлюза

2. с этого IP скачать boot.torrent по http, и если получится, тогда запустить transmission, который после скачивания торрента выполнит kexec

3. ну ещё попытаться скачать boot.iso по http, если boot.torrent недоступен, всё лучше чем TFTP.

оба шаблона собираются двумя командами:

boobstrap build --template crux-netboot.example

на выходе получим *.rootplug файл, на его основе соберётся второй шаблон

boobstrap build --template crux-netboot-p2p-bittorrent.example

и во втором случае получим загрузочный ISO, который выполняет всё то, что указано в шаблоне, т.е. вот всю эту муть с transmission.

как вам такие костыли?

Spoofing ★★★★★ ()
Ответ на: комментарий от commagray

А что по времени распаковки?

60 vs 40 МБ в условиях NVMe SSD можно смело пренебречь, например.

pekmop1024 ★★★★★ ()
Ответ на: комментарий от Spoofing

1. узнать IP шлюза

2. с этого IP скачать boot.torrent по http,

а какая тут связь? и зачем узнавать?

т.е. шлюз - это просто шлюз в другую сеть. в общем случае на нём никаких твоих сервисов дополнительных может не быть.

но это мелочи посути.

как насчет того, чтобы через параметры ядра передавать ип-адрес сервера с payload-ом через конфиги pxe.

например: BOOBS_IP=<y.x.z.q>

на этом адресе будет http, c нужной структурой и конфигами.

скрипт будет брать оттуда конфиг и возможно выполнять какие-то другие скрипты, если потребуется.

т.е. абстрактная задача такая: как-то явно передать откуда брать payload и уже потом его выполнить. нюансы и детали - как угодно.

гадание - это хорошо, но тогда тебе придется постоянно пересобирать всё, чтобы что-то поменять в том скрипте.

предлагаю мыслить в сторону data driven решений.

как вам такие костыли?

в индустрии это называется PoC (пок, поц, proof of concept)

n_play ()

Самый маленький и самый быстрый initramfs получается с MODULES=dep, а не перебором методов сжатия.

aidaho ★★★★★ ()

Initrd вообще не нужен.

У меня ведро 5.6 занимает 8.6 мегабайта - и туда вкомпилено все что нужно. Прекрасно работает без initrd’ов.

windows10 ★★ ()
Ответ на: комментарий от windows10

главное бэкапы делать не забывай, а то линукс переустанавливать придётся. =)

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

Да че бэкапить на локалхосте-то ? Разве что сейвы скайрима )

windows10 ★★ ()
Ответ на: комментарий от Spoofing

Да, спасибо. Конфиг - отлично. Научи boobstrap искать его в ~/.config. Тупо в /etc его класть не очень хорошо. Лучше в /etc/boobstrap/. Пример конфига так же хорошо иметь в /usr/share/boobstrap. Цвета - приколько :).

Но у меня проблема с твоим lddtree. Он ничего не хочет копировать нормально. Патчить самому лень, по-этому тебя буду пинать :D

ldd: ./=>: Нет такого файла или каталога
      =>
        Failure []
      /lib64/ld-linux-x86-64.so.2
        Failure []
      /usr/bin/mv
        Failure []
      /usr/lib64/ld-linux-x86-64.so.2
        Failure []
      /usr/lib/ld-linux-x86-64.so.2
        Failure []
      /usr/lib/libacl.so.1
        Failure []
      /usr/lib/libattr.so.1
        Failure []
      /usr/lib/libc.so.6
        Failure []
Difrex ★★★★ ()
Последнее исправление: Difrex (всего исправлений: 1)
Ответ на: комментарий от Difrex

ахахах скажи лучше бы вместо свистелок перделок сделал чтобы работало нормально :D в итоге вообще всё сломал.

сейчас манжару скачаю, потыкаюсь что там.

multiboot usb попозже гляну, сперва сделаю чтоб везде работало))

Spoofing ★★★★★ ()
Ответ на: комментарий от Spoofing

всё это в tmpfs.

Лучше используй zram,

  1. в отличии от tmpfs хранимые файлы будут сжиматься.
  2. можно использовать реальные fs со всеми их фичами
  3. Вместо разархивации и архивации используется более простая запись raw образа накопителя.
  4. Не уверен, но вроде как занимает ОЗУ сразу что позволяет избежать неожиданного окончания памяти.
torvn77 ★★★★★ ()
Ответ на: комментарий от Spoofing

Действительно, zstd быстрее, в интернетах озвучивали цифры аж в 1300%, правда не помню с чем сравнивали, но не суть. Хотелось бы чтоб поскорее это включили в ядро, чтоб можно было по-человечески initrd распаковать.

Основная задержка в загрузке initrd это не распаковка, а его загрузка с его места хранения, на фоне чего процесс разорхивации практически не заметен.

По этому наибольшее увеличение эфективности загрузки initrd даст алгоритм обеспечивающий максимальную степень сжатия, а не скорость распаковки.

torvn77 ★★★★★ ()
Ответ на: комментарий от torvn77

НЭД.

[ntfs-a320mh ntfs]# cd /
[ntfs-a320mh /]# fallocate -l 2G test.raw
[ntfs-a320mh /]# zip test.zip test.raw
  adding: test.raw (deflated 100%)
[ntfs-a320mh /]# ls -lah | grep test
-rw-r--r--   1 root root 2.0G Jun 14 17:11 test.raw
-rw-r--r--   1 root root 2.0M Jun 14 17:11 test.zip
[ntfs-a320mh /]# time cat test.raw > /ssd/test.raw

real	0m17.004s
user	0m0.010s
sys	0m3.845s
[ntfs-a320mh /]# time zcat test.zip > /ssd/test.unpacked

real	0m27.215s
user	0m11.493s
sys	0m2.008s
[ntfs-a320mh /]#

В первом случае с носителя прочитались два гига, и два гига записались на другой раздел.

Во втором случае прочитались всего два мегабайта, произошла распаковка двухгигового файла, и два гига записались на другой раздел.

В первом случае 17 секунд. Во втором случае 27 секунд.

windows10 ★★ ()
Ответ на: комментарий от windows10

Это уже в запущенной ОС, при загрузке же твой двухгиговый initrd может читаться с диска несколько минут, если не дольше.

torvn77 ★★★★★ ()
Последнее исправление: torvn77 (всего исправлений: 3)
Ответ на: комментарий от torvn77

Вообще в прошлом, когда компы были чуть потупее, SSD’ов почти не было, а я был фанатом яста - мой комп надо было частенько перезагружать и меня этот момент бесил. Я тогда вынес /boot отдельным разделом с какой-то очень тупой ФС, то ли ext2 то ли вообще fat16, и сие действо ускорило загрузку на порядок.

Но в 2020-м сдается мне, что если даже Sраный ATA может отдавать 650 мб\сек, то временем чтения парумегабайтного файла, можно пренебречь.

windows10 ★★ ()
Ответ на: комментарий от windows10

что если даже Sраный ATA может отдавать 650 мб\сек

В загруженной ОС, а не в BIOS.

torvn77 ★★★★★ ()
Ответ на: комментарий от Difrex

ну вроде починил. довольно странно что grep -o имеют разное поведение в разных дистрах. при том что версии библиотек, зависимостей — одинаковые.

Spoofing ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)