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

А где lz4?

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

# 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

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

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

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

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

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

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

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

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

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

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

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

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

pigz

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

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

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

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

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

boobs trap

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

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

Я все жду PAQ

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

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

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

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

сейчас уже подумываю сделать 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

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

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

Спасибо, Facebook.

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

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

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

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

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

Ну понятно, у них там своё ядро с патчами, ага. https://git.archlinux.org/linux.git

Дождёмся в ванильке.

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

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

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

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

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

А смысл, если есть lz4, который быстрее?

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

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

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

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

Да, прикольно :)

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

там это, обновление прилетело ))

http://dl.voglea.com/colours.png

# git clone https://github.com/sp00f1ng/boobstrap.git
# boobstrap/tests/crux-download-and-build

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

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

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

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

Да, спасибо. Конфиг - отлично. Научи 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 []

Да, еще. Получающийся образ не работает с multiboot usb.

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

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

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

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

https://files.catbox.moe/cmgipj.png

всё это в tmpfs.

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

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

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

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

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

НЭД.

[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 секунд.

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

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

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

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

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

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