PXELinux и сжатые ядра / образы

818
friedkiwi

Можно ли загружать сжатые ядра со сжатым initrd с помощью PXELinux?

Сначала немного предыстории:

Мы создали специальный дистрибутив Linux для бездисковых вычислительных узлов OpenCL. Мы хотим, чтобы эти узлы извлекали свои ОС из сети. Наш дистрибутив состоит из ядра (duh) и большого initrd, который загружается в RAM, и все выполняется оттуда.

Мы решили запустить все из initrd по двум причинам:

  • NFS не была опцией для обслуживания дополнительного содержимого файловой системы
  • Быстрый доступ к файлам из оперативной памяти.
  • Постоянное хранилище не требуется, данные и конфигурация динамически передаются через службу SOAP.

Теперь наш initrd размером около 450M. При скорости нашей сети загрузка одного клиента занимает около двух-трех минут. Будет ли сжатие ускорять загрузку, и если да, какой из них следует использовать? Поддерживается ли LZMA PXELinux, или нам нужно придерживаться bzip2 или gzip?

Из-за 2-3 минут загрузки загрузка 15 узлов по одному и тому же сетевому каналу занимает довольно много времени. Мы решили не использовать жесткие диски или приводы CD / DVD по финансовым причинам (самый дешевый жесткий диск при 30 евро в 15 раз сэкономил ;-))

Итак, наш вопрос: какие параметры сжатия доступны для этой настройки? И как мы это делаем?

Спасибо за ваше время!

Иван Янссенс

3
Вы уже оптимизировали свой дистрибутив? Удалите всю документацию, библиотеки, включения, локали, которые вам не нужны, удалите двоичные файлы и библиотеки символов отладки, перекомпилируйте с оптимизацией для размера ... Marcin 13 лет назад 0

3 ответа на вопрос

1
Turbo J

Как вы сделали initrd? Большинство известных мне систем сжимают их на последнем этапе:

> file /boot/initrd-2.6.37.1-1.2-desktop /boot/initrd-2.6.37.1-1.2-desktop: gzip compressed data, [...]

Ядро должно поддерживать сжатие:

> cat /boot/config-2.6.37.1-1.2-desktop |grep CONFIG_RD_ CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_RD_LZO=y

Но 450 МБ RAM-диска означает 450 МБ меньше памяти - и без жесткого диска у вас нет подкачки.

Вы должны серьезно взглянуть на сетевую файловую систему, там больше, чем NFS: gPXE может загружаться из iSCSI, AoE и даже HTTP.

Все узлы имеют 2 ГБ оперативной памяти, а ОС и приложения работают на 256 МБ, 512 МБ в пике. Таким образом, остается виртуальный диск размером 1250 МБ ;-). Тем временем 450 МБ уменьшается до 250 МБ, удаляя ненужные вещи. Это сжатый размер, изображение 1024 МБ. friedkiwi 13 лет назад 0
Если вы не используете squashfs, ** несжатый ** образ будет в ОЗУ. Не оставляет много места в вашем случае. Turbo J 13 лет назад 0
Да, знаю. 2 ГБ ОЗУ, 1 ГБ Ramdrive, 1 ГБ Рабочая память Должно быть достаточно только для консоли, верно? friedkiwi 13 лет назад 0
0
darkdragn

У вас есть хотя бы о реализации Каспер и Squashfs. Таким образом, вы можете сохранить initrd минимальным размером, может быть, около 25 МБ и отправить squashfs отдельно. Squashfs поддерживает сжатие lzma, и если вы посмотрите, как с этим справляется parted magic, иногда они помещают squashfs в initrd ... однако в прошлом я играл с pxelinux, и вместо этого вы можете отправить его в виде отдельного файла. и сценарии Каспера все равно найдут его.

Удаление большего количества даты из изображения, путем удаления символов отладки и программ / библиотек разработки сделали свое дело. Теперь изображение сжато до 260M, что для меня приемлемо, поскольку оно передается через соединение GBit (на передачу требуется около 25 секунд). friedkiwi 13 лет назад 0
0
Pat

1) типичное ядро ​​Linux сжато, то же самое для его initrd, проверьте цепочку сборки.

2) ваши цифры говорят, что вам не нужны сквош

3) pxelinux не заботится о вашем методе сжатия ядра / initrd, если таковой имеется.

Похожие вопросы