Как обычно, в Ташкенте в субботу снова пройдет семинар по линуксу. В этот раз затронем тему пакетных менеджеров в линуксе. Вот готовлю материал уже. Подробнее тут:
http://forum.linux.uz/index.php/topic,1009.0.html
И тут:
http://forum.linux.uz/index.php/topic,1002.0.html
понедельник, 3 августа 2009 г.
пятница, 24 июля 2009 г.
".deb" пакеты изнутри
Эта интересная штука пришла к нам от дебиана (http://ru.wikipedia.org/wiki/Debian). Собственно, "deb" - это есть сокращение от "debian".
http://ru.wikipedia.org/wiki/Deb_(%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2)
http://ru.wikipedia.org/wiki/Dpkg
http://ru.wikipedia.org/wiki/Deb_(%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2)
http://ru.wikipedia.org/wiki/Dpkg
четверг, 23 июля 2009 г.
Отключаем initrd в убунте.
Недавно провел эксперимент - просто отключил в грабе initrd. Система спокойно и без ругани загрузилась. Самые необходимые модули уже встроены в ядро, даже ext4. Можете проверить сами и убедиться.
В грабе, на строчке с выбором ядра, жмем букву "e" на клаве, стрелками выбираем строчку со словом "initrd" и нажимаем букву "d". Далее стрелками снова выбираем строчку со словом "kernel ..." и секцию "root=UUID=........." заменяем на "root=/dev/sdaX", где Х - номер раздела, куда установлена убунту. Нажимаем "ENTER" и потом букву "b". Если система загрузится нормально - можете уже исправить конфиг граба. Убунту будет грузиться еще быстрее.
Чтобы отключить уже в грабе, достаточно открыть его конфиг
gksudo gedit /boot/grub/menu.lst
найти там строчку типа
initrd /boot/initrd.img-2.6.28-14-generic
и закомментировать ее, то есть поставить перед ней знак решетки "#"
# initrd /boot/initrd.img-2.6.28-14-generic
Кто использует уже скомпиленные ядра в deb-пакетах, скаченные с http://kernel.ubuntu.com/~kernel-ppa/mainline/, может тоже уже не использовать initrd.
Только хочу предупредить, что initrd все равно иногда просто необходим системе. Например, если у вас проблемы с файловой системой, инитрд сначала проверить ее на ошибки, исправит их, а потом только подмонтирует и продолжит загрузку. Единственный плюс от его отключения - это опять уменьшение времени загрузки убунты.
В грабе, на строчке с выбором ядра, жмем букву "e" на клаве, стрелками выбираем строчку со словом "initrd" и нажимаем букву "d". Далее стрелками снова выбираем строчку со словом "kernel ..." и секцию "root=UUID=........." заменяем на "root=/dev/sdaX", где Х - номер раздела, куда установлена убунту. Нажимаем "ENTER" и потом букву "b". Если система загрузится нормально - можете уже исправить конфиг граба. Убунту будет грузиться еще быстрее.
Чтобы отключить уже в грабе, достаточно открыть его конфиг
gksudo gedit /boot/grub/menu.lst
найти там строчку типа
initrd /boot/initrd.img-2.6.28-14-generic
и закомментировать ее, то есть поставить перед ней знак решетки "#"
# initrd /boot/initrd.img-2.6.28-14-generic
Кто использует уже скомпиленные ядра в deb-пакетах, скаченные с http://kernel.ubuntu.com/~kernel-ppa/mainline/, может тоже уже не использовать initrd.
Только хочу предупредить, что initrd все равно иногда просто необходим системе. Например, если у вас проблемы с файловой системой, инитрд сначала проверить ее на ошибки, исправит их, а потом только подмонтирует и продолжит загрузку. Единственный плюс от его отключения - это опять уменьшение времени загрузки убунты.
вторник, 14 июля 2009 г.
Программа "/sbin/init" и стартовые скрипты. Часть 1.
После того, как grub загрузил ядро линукса, это самое ядро по умолчанию запускает программу "/sbin/init" (в параметрах ядра можно указать другой путь до этой программы, "init=/usr/bin/my_init" к примеру или "init=/bin/bash" - чтобы запустить напрямую после ядра сразу bash). Ядро может запустить только одну программу, но эта программа должна взять на себя обязанность загружать все остальное. В winnt, кстати, используется почти такая же система - там роль "/sbin/init" играет программа "smss.exe". Сейчас, с использованием initrd-образов в большинстве дистрибутивах, программа init сначала запускается с этого самого образа, но потом все равно запускает "/sbin/init" с корневого раздела. Для того, чтобы легче было манипулировать с настройками загрузки системы и чтобы проще было добавлять сторонние программы в "автозагрузку", init использует конфиги, скрипты и т.д. Чаще всего - в текстовом формате. То есть, ядро запускает "/sbin/init", а тот в свою очередь уже запускает по порядку стартовые скрипты или парсит текстовый конфиг. В некоторых случаях же, "/sbin/init" сам представляет из себя шелл-скрипт, как на том-же образе initrd.
Загрузка всей системы - довольно сложный процесс. В него входит инициализация udev, hal и многого другого. Ради гибкости настроек и совместимости, в большинстве случаев, теряется производительность. Скрипты и конфиги для инита уже переросли в целые системы, пакеты с кучей файлов.
Долгое время в *NIX системах использовалась система стартовых скриптов sysvinit. Сейчас же sysvinit сильно устарел и на его смену пришло очень много других вариантов - InitNG, Upstart, runit, eINIT, Kyuba... В убунте к примеру уже используется upstart, в генту - initng.
В общем, в следующих частях этой темы и опишу различия этих систем, сделаю краткий обзор. Потом постараюсь описать работу убунтовского Upstart. А в будущем, с друзьями, планирую написать свой простенький init. В основном ради экспериментов, для опыта и для примеров.
Загрузка всей системы - довольно сложный процесс. В него входит инициализация udev, hal и многого другого. Ради гибкости настроек и совместимости, в большинстве случаев, теряется производительность. Скрипты и конфиги для инита уже переросли в целые системы, пакеты с кучей файлов.
Долгое время в *NIX системах использовалась система стартовых скриптов sysvinit. Сейчас же sysvinit сильно устарел и на его смену пришло очень много других вариантов - InitNG, Upstart, runit, eINIT, Kyuba... В убунте к примеру уже используется upstart, в генту - initng.
В общем, в следующих частях этой темы и опишу различия этих систем, сделаю краткий обзор. Потом постараюсь описать работу убунтовского Upstart. А в будущем, с друзьями, планирую написать свой простенький init. В основном ради экспериментов, для опыта и для примеров.
Программа "/sbin/init" и стартовые скрипты. Часть 2.
Краткий обзор некоторых клонов init:
Upstart (http://upstart.ubuntu.com/ http://en.wikipedia.org/wiki/Upstart)
Загружает сервисы по событиям.
InitNG (http://www.initng.org/ http://en.wikipedia.org/wiki/Initng)
eINIT (http://en.wikipedia.org/wiki/Einit)
minit (http://www.fefe.de/minit/)
cinit (http://linux.schottelius.org/cinit/)
twsinit (http://www.energymech.net/users/proton/)
runit (http://smarden.org/runit/)
Kyuba (http://kyuba.org/)
myinit (http://sourceforge.net/projects/myinit/)
Ссылки:
http://www.freesource.info/wiki/TZ/initscripts?show_files=1 (Описание работы sysvinit, upstart и initng на русском языке)
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/ru-RU/Installation_Guide/s2-boot-init-shutdown-init.html
http://en.wikipedia.org/wiki/Init (Страница о /sbin/init в википедии на английском языке)
http://www.busybox.net/
http://users.rsise.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html (Описание загрузки линукса от включения питания до приглашения bash на английском языке)
http://wiz.su/2008/03/06/kak-zagruzhaetsya-linux/ (Пример использования runit с простыми скриптами - на русском языке)
http://ru.wikipedia.org/wiki/Процесс_загрузки_Linux (Процесс загрузки Linux в википедии на русском языке)
http://www.linuxshare.ru/docs/distro/lfs/lfs6/chapter07/usage.html (Информация о работе стартовых скриптов из LFS, тоже на русском языке)
http://wiki.kryukov.biz/wiki/Система_инициализации_Slackware_Linux (Инит-скрипты в слаке, на русском)
Upstart (http://upstart.ubuntu.com/ http://en.wikipedia.org/wiki/Upstart)
Загружает сервисы по событиям.
InitNG (http://www.initng.org/ http://en.wikipedia.org/wiki/Initng)
eINIT (http://en.wikipedia.org/wiki/Einit)
minit (http://www.fefe.de/minit/)
cinit (http://linux.schottelius.org/cinit/)
twsinit (http://www.energymech.net/users/proton/)
runit (http://smarden.org/runit/)
Kyuba (http://kyuba.org/)
myinit (http://sourceforge.net/projects/myinit/)
Ссылки:
http://www.freesource.info/wiki/TZ/initscripts?show_files=1 (Описание работы sysvinit, upstart и initng на русском языке)
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/ru-RU/Installation_Guide/s2-boot-init-shutdown-init.html
http://en.wikipedia.org/wiki/Init (Страница о /sbin/init в википедии на английском языке)
http://www.busybox.net/
http://users.rsise.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html (Описание загрузки линукса от включения питания до приглашения bash на английском языке)
http://wiz.su/2008/03/06/kak-zagruzhaetsya-linux/ (Пример использования runit с простыми скриптами - на русском языке)
http://ru.wikipedia.org/wiki/Процесс_загрузки_Linux (Процесс загрузки Linux в википедии на русском языке)
http://www.linuxshare.ru/docs/distro/lfs/lfs6/chapter07/usage.html (Информация о работе стартовых скриптов из LFS, тоже на русском языке)
http://wiki.kryukov.biz/wiki/Система_инициализации_Slackware_Linux (Инит-скрипты в слаке, на русском)
пятница, 10 июля 2009 г.
Linux-Сообщество Узбекистана
Так как решил снова заняться сообществом, большинство моих сил будут направлены на
http://www.linux.uz
Со временем, допишу все свои статьи и перетащу туда, а пока все-таки буду писать сначала сюда, как в черновик.
вторник, 7 июля 2009 г.
Патчим ядро 2.6.30 для поддержки aufs и unionfs
git clone http://git.c3sl.ufpr.br/pub/scm/aufs/aufs2-standalone.git aufs2-standalone.git
cd aufs2-standalone.git
git checkout origin/aufs2-30
cp -rvi fs/ ../kernel/linux-2.6.30/
cp -rvi include/ ../kernel/linux-2.6.30/
cp -rvi Documentation/ ../kernel/linux-2.6.30/
cd ../kernel/linux-2.6.30
patch -p1 < ../../aufs2-standalone.git/aufs2-kbuild.patch
patch -p1 < ../../aufs2-standalone.git/aufs2-standalone.patch
#wget -c http://download.filesystems.org/unionfs/unionfs-2.x/unionfs-2.5.2_for_2.6.30.diff.gz
#gzip -d unionfs-2.5.2_for_2.6.30.diff.gz
#cd ../kernel/linux-2.6.30
#patch -p1 < ../patches/unionfs-2.5.2_for_2.6.30.diff
cp /boot/config-2.6.30-020630-generic ./.config
sudo apt-get install kernel-package
export CONCURRENCY_LEVEL=3
Aufs (AnotherUnionFS)
Aufs - это "вспомогательная файловая система для каскадно-объединенного монтирования". То есть, говоря простым языком, это файловая система, которая позволяет, например, смонтировать две файловые систему в одну папку, но с разными параметрами. Ее обычно используют на Live-CD дистрибутивах - на них нет возможности записи файлов, так как диск монтируется в режиме read-only. Там и необходима штука типа aufs. Она монтирует read-only фс и фс в оперативной памяти в одну фс. В итоге получается, что все изменения read-only фс записываются в оперативную память.
понедельник, 6 июля 2009 г.
Initial RAM-Disk (initrd)
В большинстве дистрибутивах используется один очень полезный костыль - это initrd - Initial RAM disk, что по русски звучит круче - "диск в оперативной памяти для начальной инициализации". По названию и по некоторому опыту можно самостоятельно понять, что это некий образ диска, который грузиться в начале старта системы и используется для ее инициализации.
На деле - этот файл уже не является образом. Ветка ядер 2.6 уже поддерживает помимо образов еще и cpio архивы. То есть сейчас, файл initrd.img представляет из себя cpio-архив, сжатый обычно gzip'ом, внутри которого урезанная корневая файловая система. То есть, в нем те-же каталоги "/bin", "/etc" и т.д., но только не целиком взятые с основной корневой фс, а только лишь с необходимыми файлами для загрузки системы. То есть, там естественно будут утилиты типа "insmod", чтобы подгружать модули, "mount", чтобы монтировать уже настоящею корневую систему и т.д. Еще там находятся необходимые для загрузки модули - ведь ядро, например, не сможет получить доступ к файловой системе, поддержка которой скомпилена модулем, а сам модуль находиться на этой ФС. То есть ядро не сможет прочитать модуль с этой ФС, пока не загрузит этот модуль. Немного смешно звучит конечно, но собственно для таких целей и используется initrd. В нем просто находятся модули файловых систем, модули контроллеров жестких дисков и т.д.
Работает это все очень просто. Загрузчик, типа grub, загружает ядро линукса и в параметрах передает этому ядру файлик initrd. Ядро загружается, загружает в память содержимое initrd, запускает в нем программу "/sbin/init" которая уже задачи загрузки берет на себя. Подгружаются необходимые модули, монтируются файловые системы и дальше initrd передает уже управление загрузкой на основной корневой системе.
В разных дистрибутивах состав этого образа не одинаковый. Поэтому разберу его на примере уже в следующей теме.
На деле - этот файл уже не является образом. Ветка ядер 2.6 уже поддерживает помимо образов еще и cpio архивы. То есть сейчас, файл initrd.img представляет из себя cpio-архив, сжатый обычно gzip'ом, внутри которого урезанная корневая файловая система. То есть, в нем те-же каталоги "/bin", "/etc" и т.д., но только не целиком взятые с основной корневой фс, а только лишь с необходимыми файлами для загрузки системы. То есть, там естественно будут утилиты типа "insmod", чтобы подгружать модули, "mount", чтобы монтировать уже настоящею корневую систему и т.д. Еще там находятся необходимые для загрузки модули - ведь ядро, например, не сможет получить доступ к файловой системе, поддержка которой скомпилена модулем, а сам модуль находиться на этой ФС. То есть ядро не сможет прочитать модуль с этой ФС, пока не загрузит этот модуль. Немного смешно звучит конечно, но собственно для таких целей и используется initrd. В нем просто находятся модули файловых систем, модули контроллеров жестких дисков и т.д.
Работает это все очень просто. Загрузчик, типа grub, загружает ядро линукса и в параметрах передает этому ядру файлик initrd. Ядро загружается, загружает в память содержимое initrd, запускает в нем программу "/sbin/init" которая уже задачи загрузки берет на себя. Подгружаются необходимые модули, монтируются файловые системы и дальше initrd передает уже управление загрузкой на основной корневой системе.
В разных дистрибутивах состав этого образа не одинаковый. Поэтому разберу его на примере уже в следующей теме.
пятница, 26 июня 2009 г.
Убунтовские патчи для ядра
Есть такое выражение - "ванильное ядро". Оно означает "чистое", "без примесей" ядро линукса с сайта www.kernel.org, то есть без каких-либо изменений в исходном коде. Большинство разработчиков дистрибутивов изменяют исходники, дабы добавить какой-нибудь дополнительный функционал, исправить ошибки или еще что-нибудь. Не обошлось без этого и в убунте, где в ядро добавлено много своих и сторонних патчей. К сожалению, в интернете очень тяжело найти весь перечень этих патчей, я лично так и не нашел, поэтому пришлось разбираться самому.
Вот только то, что я сумел откопать:
* UnionFS (www.filesystems.org/project-unionfs.html) - "вспомогательная файловая система для Linux и FreeBSD, производящая каскадно-объединённое монтирование других файловых систем." Применяется в LiveCD убунты - так как LiveCD в режиме только для чтения, а некоторые файлы все равно должны изменяться в процессе работы системы - эта ФС записывает измененные файлы в оперативную память, а система видит эти измененные файлы, как будто они записаны в файловой системе LiveCD. То есть совмещает две ФС в одну.
* Aufs (aufs.sourceforge.net) - тоже самое, что UnionFS, только считается чуть лучшим
* SquashFS - ну об этом уже много раз писал...
* compcache (code.google.com/p/compcache) - сжимает данные в разделе подкачки, тем самым экономит оперативную память
Вот только то, что я сумел откопать:
* UnionFS (www.filesystems.org/project-unionfs.html) - "вспомогательная файловая система для Linux и FreeBSD, производящая каскадно-объединённое монтирование других файловых систем." Применяется в LiveCD убунты - так как LiveCD в режиме только для чтения, а некоторые файлы все равно должны изменяться в процессе работы системы - эта ФС записывает измененные файлы в оперативную память, а система видит эти измененные файлы, как будто они записаны в файловой системе LiveCD. То есть совмещает две ФС в одну.
* Aufs (aufs.sourceforge.net) - тоже самое, что UnionFS, только считается чуть лучшим
* SquashFS - ну об этом уже много раз писал...
* compcache (code.google.com/p/compcache) - сжимает данные в разделе подкачки, тем самым экономит оперативную память
вторник, 23 июня 2009 г.
SquashFS. Тестирование
В тестировании использовалось ядро 2.6.30 с поддержкой squashfs версии 4.0 и утилиты squashfs-tools тоже версии 4.0. Естественно, как обычно тесты просто "посмотреть", но все равно полезно интересующимся.
Для тестирования взял каталог /usr почти на свеже-установленной системе, размером в 2076824Кб, почти в два гигабайта. Сжал в образ squashfs вот так:
То есть используя параметры по умолчания (размер блока - 128кб). Файловая система создалась за 6 минут и 4 секунды. Файл usr.sqs сжался до размера 683924Кб. Следовательно, размер файла сократился ровно в три раза, что есть очень сильно... С использованием других параметров, особо ничего не изменилось (даже размер блока в мегабайт не дал особых результатов).
Ладно, скорость сжатия не низкая, несмотря на сильное сжатие. Но интересней больше скорость чтения, по теории она должна быть выше, чем работа с файлами на обычной файловой системе. На практике это подтвердилось. На копирование всех файлов с подмонтированной squashfs ушло 2 минуты и 18 секунд, а на копирование всех тех-же файлов с каталога /usr ушло 4 минуты и 58 секунд. Однако в первом случае, возросла нагрузка на процессор - в среднем 30%, а во втором случае - всего 8%. То есть, теория подтвердилась полностью, но нагрузка на процессор с использованием squashfs не такая уж сильная.
В итоге, пока так и не стало все полностью понятным. В интернете отсутствует подробная информация. Но по крайней мере понятно то, что squashfs справляется со своими задачами очень даже хорошо. На данный момент, на сколько я понял, утилиты squashfs и сама поддержка файловой системы в ядре, сжимают информацию с использованием gzip, когда как раньше были патчи, позволяющие использовать lzma. Буду копать дальше...
Для тестирования взял каталог /usr почти на свеже-установленной системе, размером в 2076824Кб, почти в два гигабайта. Сжал в образ squashfs вот так:
sudo mksquashfs /usr /usr.sqs
То есть используя параметры по умолчания (размер блока - 128кб). Файловая система создалась за 6 минут и 4 секунды. Файл usr.sqs сжался до размера 683924Кб. Следовательно, размер файла сократился ровно в три раза, что есть очень сильно... С использованием других параметров, особо ничего не изменилось (даже размер блока в мегабайт не дал особых результатов).
Ладно, скорость сжатия не низкая, несмотря на сильное сжатие. Но интересней больше скорость чтения, по теории она должна быть выше, чем работа с файлами на обычной файловой системе. На практике это подтвердилось. На копирование всех файлов с подмонтированной squashfs ушло 2 минуты и 18 секунд, а на копирование всех тех-же файлов с каталога /usr ушло 4 минуты и 58 секунд. Однако в первом случае, возросла нагрузка на процессор - в среднем 30%, а во втором случае - всего 8%. То есть, теория подтвердилась полностью, но нагрузка на процессор с использованием squashfs не такая уж сильная.
В итоге, пока так и не стало все полностью понятным. В интернете отсутствует подробная информация. Но по крайней мере понятно то, что squashfs справляется со своими задачами очень даже хорошо. На данный момент, на сколько я понял, утилиты squashfs и сама поддержка файловой системы в ядре, сжимают информацию с использованием gzip, когда как раньше были патчи, позволяющие использовать lzma. Буду копать дальше...
SquashFS. Введение
В ядро версии 2.6.29 внесли наконец поддержку squashfs. Это значит, что теперь эта файловая система поддерживается в самом ядре, без дополнительных патчей.
SquashFS - это файловая система, наподобие CramFS и Cloopfs. Эта файловая система поддерживает сжатие, причем даже уже мое любимое - LZMA. Применяется в основном на livecd и во встраеваемых устройствах. Работает только в режими чтения, то есть, внести новый файл или уже изменить существующий "на лету" никак не получиться.
Вы можете встретить ее на обычном livecd диске убунты. Файл SquashFS-образа находиться в папке casper на диске с убунтой и называется filesystem.squashfs. Если в ядре есть поддержка данной файловой системе, то вам достаточно лишь примонтировать этот файл, как вы монтировали когда-то обычные ".iso" образы:
В каталоге /mnt вы увидете структуру каталогов обычного дистрибутива линукса. Это и есть дистрибутив убунты. Убунту грузиться с компакт-диска монтирует данный файл и с помощью chroot запускает уже целиком систему. Если же вы начали инсталлировать убунту, то инсталлятор просто копирует содержимое данного файла на корневой раздел вашего винчестера. Ну дальше он доставляет некоторый софт, конфигурирует систему и т.п.
Получить файлы из этой файловой системы можно и другим способом. Помимо реализации самой данной файловой системы, существуют так-же и утилиты для управления ею. Скачать их можно отсюда. Они, конечно, есть и в стандартном репозитарии убунты:
Но эти утилиты и сама ФС в убунте обновлялись очень давно. В дистрибутиве до сих пор используется версия SquashFS за 2007 год, когда уже актуальная вышедшая в этом году четвертая версия. Поэтому лучше всего использовать ядро выше версии 2.6.29 и утилиты компилить вручную. Ну по крайней мере до тех пор, пока это чудо не обновиться в убунте.
Так вот, с помощью утилиты mksquashfs можно с легкостью создать данную файловую систему:
Или распаковать ее:
Преимуществ у данной ФС много. Помимо всего прочего - она использует очень сильное сжатие. Файлы сжимаются в два-три раза, причем на довольно высокой скорости. Чтобы достать один файл, не нужно распаковывать всю файловую систему целиком (как это делается с обычными архивами - tar.bz2 и т.п. - попробуйте распаковать всего один самый маленький файл из архива с исходниками ядра), а достаточно лишь ее подмонтировать. Скорость распаковки тоже впечатляет. Да и операции с файлами на такой ФС быстрее, так как файлы занимают в дво-трое меньший размер, чем в реальности. То есть скорость того-же копирования - в два-три раза быстрее, чем с обычной ФС. Из недостатков только то, что операции с файлами на данной ФС больше используют мощности процессоров, но на современных компьютерах это не заметно, а на встраеваемой технике обычно размер играет большее значение.
SquashFS - это файловая система, наподобие CramFS и Cloopfs. Эта файловая система поддерживает сжатие, причем даже уже мое любимое - LZMA. Применяется в основном на livecd и во встраеваемых устройствах. Работает только в режими чтения, то есть, внести новый файл или уже изменить существующий "на лету" никак не получиться.
Вы можете встретить ее на обычном livecd диске убунты. Файл SquashFS-образа находиться в папке casper на диске с убунтой и называется filesystem.squashfs. Если в ядре есть поддержка данной файловой системе, то вам достаточно лишь примонтировать этот файл, как вы монтировали когда-то обычные ".iso" образы:
mount -o loop /media/cdrom/casper/filesystem.squashfs /mnt
В каталоге /mnt вы увидете структуру каталогов обычного дистрибутива линукса. Это и есть дистрибутив убунты. Убунту грузиться с компакт-диска монтирует данный файл и с помощью chroot запускает уже целиком систему. Если же вы начали инсталлировать убунту, то инсталлятор просто копирует содержимое данного файла на корневой раздел вашего винчестера. Ну дальше он доставляет некоторый софт, конфигурирует систему и т.п.
Получить файлы из этой файловой системы можно и другим способом. Помимо реализации самой данной файловой системы, существуют так-же и утилиты для управления ею. Скачать их можно отсюда. Они, конечно, есть и в стандартном репозитарии убунты:
apt-get install squashfs-tools
Но эти утилиты и сама ФС в убунте обновлялись очень давно. В дистрибутиве до сих пор используется версия SquashFS за 2007 год, когда уже актуальная вышедшая в этом году четвертая версия. Поэтому лучше всего использовать ядро выше версии 2.6.29 и утилиты компилить вручную. Ну по крайней мере до тех пор, пока это чудо не обновиться в убунте.
Так вот, с помощью утилиты mksquashfs можно с легкостью создать данную файловую систему:
mksquashfs /usr /usr.squashfs
Или распаковать ее:
unsquashfs /media/cdrom/casper/filesystem.squashfs -d /ubuntu_live
Преимуществ у данной ФС много. Помимо всего прочего - она использует очень сильное сжатие. Файлы сжимаются в два-три раза, причем на довольно высокой скорости. Чтобы достать один файл, не нужно распаковывать всю файловую систему целиком (как это делается с обычными архивами - tar.bz2 и т.п. - попробуйте распаковать всего один самый маленький файл из архива с исходниками ядра), а достаточно лишь ее подмонтировать. Скорость распаковки тоже впечатляет. Да и операции с файлами на такой ФС быстрее, так как файлы занимают в дво-трое меньший размер, чем в реальности. То есть скорость того-же копирования - в два-три раза быстрее, чем с обычной ФС. Из недостатков только то, что операции с файлами на данной ФС больше используют мощности процессоров, но на современных компьютерах это не заметно, а на встраеваемой технике обычно размер играет большее значение.
пятница, 19 июня 2009 г.
Снова ".deb" и lzma
В сети пока не легко найти инфу по архиватору lzma, который вроде не такой уж новый, но популярность начал обретать лишь недавно. Мой скрипт по перепаковки ".deb" пакетов из bz2/gz в lzma слишком сырой и кривой. Однако не только я, оказывается, интересовался этой проблемой. Есть уже более подробная информация и более подробным сравнением. Встречайте:
https://wiki.ubuntu.com/dpkg-lzma
воскресенье, 14 июня 2009 г.
Отключение надоедливого спикера
Жутко раздражает меня эта пищалка. Отключается довольно просто - надо всего-лишь выгрузить модуль "pcspkr". То есть:
Но это отключит его только на данный сеанс, чтобы отказаться вообще от этой пищалки, открываем файл
И в конец добавляем строчку "blacklist pcspkr". Сохраняем и перезагружаемся, дабы проверить.
sudo modprobe -r pcspkr
Но это отключит его только на данный сеанс, чтобы отказаться вообще от этой пищалки, открываем файл
sudo gedit /etc/modprobe.d/blacklist.conf
И в конец добавляем строчку "blacklist pcspkr". Сохраняем и перезагружаемся, дабы проверить.
пятница, 12 июня 2009 г.
Скрипт для перепаковки ".deb" пакетов
Вот составил черновой вариант. Пользоваться так:
#!/bin/bash
PACKAGE=$1
PACKAGENAME=`basename ${PACKAGE}`
TMPDIR=/tmp
BUILDDIR=`echo ${PACKAGENAME} | sed s/".deb"/""/g`
mkdir ${TMPDIR}/${BUILDDIR}
cp ${PACKAGE} ${TMPDIR}/${BUILDDIR}
mv ${PACKAGE} `echo ${PACKAGE} | sed s/".deb"/"_old.deb"/g`
cd ${TMPDIR}/${BUILDDIR}
ar x ${PACKAGENAME}
mkdir DEBIAN
if [ -f control.tar.gz ]
then
tar zxf control.tar.gz -C DEBIAN
rm control.tar.gz
fi
if [ -f data.tar.gz ]
then
tar zxf data.tar.gz
rm data.tar.gz
fi
if [ -f control.tar.bz2 ]
then
tar jxf control.tar.bz2 -C DEBIAN
rm control.tar.bz2
fi
if [ -f data.tar.bz2 ]
then
tar jxf data.tar.bz2
rm data.tar.bz2
fi
rm debian-binary ${PACKAGENAME}
cd ${TMPDIR}
dpkg-deb -b -z9 -Zlzma ${BUILDDIR} `echo ${PACKAGE} | sed s/".deb"/"_lzma.deb"/g`
rm -rf ${TMPDIR}/${BUILDDIR}
deb_lzma_repack.sh /полный/путь/до/пакета/пакет.debКод:
#!/bin/bash
PACKAGE=$1
PACKAGENAME=`basename ${PACKAGE}`
TMPDIR=/tmp
BUILDDIR=`echo ${PACKAGENAME} | sed s/".deb"/""/g`
mkdir ${TMPDIR}/${BUILDDIR}
cp ${PACKAGE} ${TMPDIR}/${BUILDDIR}
mv ${PACKAGE} `echo ${PACKAGE} | sed s/".deb"/"_old.deb"/g`
cd ${TMPDIR}/${BUILDDIR}
ar x ${PACKAGENAME}
mkdir DEBIAN
if [ -f control.tar.gz ]
then
tar zxf control.tar.gz -C DEBIAN
rm control.tar.gz
fi
if [ -f data.tar.gz ]
then
tar zxf data.tar.gz
rm data.tar.gz
fi
if [ -f control.tar.bz2 ]
then
tar jxf control.tar.bz2 -C DEBIAN
rm control.tar.bz2
fi
if [ -f data.tar.bz2 ]
then
tar jxf data.tar.bz2
rm data.tar.bz2
fi
rm debian-binary ${PACKAGENAME}
cd ${TMPDIR}
dpkg-deb -b -z9 -Zlzma ${BUILDDIR} `echo ${PACKAGE} | sed s/".deb"/"_lzma.deb"/g`
rm -rf ${TMPDIR}/${BUILDDIR}
Сборка ".deb"-пакета с использованием lzma-сжатия
Решил попробовать собрать ".deb"-пакет с использованием lzma, вместо стандартного gzip и популярного bzip2. Взял уже готовый пакет с новым ядром линукса, который был в bzip2, распаковал его и собрал заново, но уже с параметрами lzma.
Вот так вот выглядит сборка:
"dpkg-deb -b -z9 -Zlzma linux-image-2.6.30-generic_i386/ linux-image-2.6.30-generic_i386.deb"
Где "-z9" - это степень сжатия, "-Zlzma" - тип сжатия.
Пакет собрался ровно за 2 минуты.
Установился обычной командой "dpkg -i linux-image-2.6.30-generic_i386.deb", всего за 13 секунд (Пакет можно устанавливать и двойным кликом или другим способом - он по-сути ничем не отличается от обычных пакетов).
Пакет с использованием bzip2 собрался за 16 секунд (конечно быстрее, чем lzma), а установился за 16 секунд.
А с gzip - почему-то собрался за 54 и установился за 18 секунд.
Разница в размере - 24Мб у пакета с использованием bzip2, 27Мб с gzip и 20Мб у пакета с использованием lzma. Что странно, пакет с использованием bzip2 собирается быстрее и быстрее ставиться, чем с gzip. А вот пакет с lzma-сжатием ставится быстрее всех, но дольше собирается.
Обычный пользователь и не заметит, с помощью какого архиватора создан пакет, который он устанавливает, но разницу в размере заметят все.
Выводы делайте уже сами)
Вот так вот выглядит сборка:
"dpkg-deb -b -z9 -Zlzma linux-image-2.6.30-generic_i386/ linux-image-2.6.30-generic_i386.deb"
Где "-z9" - это степень сжатия, "-Zlzma" - тип сжатия.
Пакет собрался ровно за 2 минуты.
Установился обычной командой "dpkg -i linux-image-2.6.30-generic_i386.deb", всего за 13 секунд (Пакет можно устанавливать и двойным кликом или другим способом - он по-сути ничем не отличается от обычных пакетов).
Пакет с использованием bzip2 собрался за 16 секунд (конечно быстрее, чем lzma), а установился за 16 секунд.
А с gzip - почему-то собрался за 54 и установился за 18 секунд.
Разница в размере - 24Мб у пакета с использованием bzip2, 27Мб с gzip и 20Мб у пакета с использованием lzma. Что странно, пакет с использованием bzip2 собирается быстрее и быстрее ставиться, чем с gzip. А вот пакет с lzma-сжатием ставится быстрее всех, но дольше собирается.
Обычный пользователь и не заметит, с помощью какого архиватора создан пакет, который он устанавливает, но разницу в размере заметят все.
Выводы делайте уже сами)
четверг, 11 июня 2009 г.
Тестирование производительности архиваторов
Вступление
В линуксе архиваторы существуют уже давно как часть GNU утилит. Ими сжимается образ ядра, мануалы, пакеты и много чего другого. Они призваны экономить место на носителях данных.
Сейчас, наиболее популярными архиваторами в линуксе являются gzip, bzip2 и сравнительно более новый архиватор - lzma. Поддержка всех этих трех архиваторов уже есть в новом ядре и в некоторых пакетных менеджерах, таких как dpkg. Это значит, что вы можете сжать ядро, чтобы оно меньше занимало места на носителе (удобно для встраеваемых устройств). Так-же, в том же дистрибутиве Ubuntu используются ".deb" пакеты, в которых находятся сжатые файлы (сами бинарники программы, документация и т.п.). В основном, для содержимого ".deb" пакетов используется gzip. Но при создании пакетов, давно можно использовать уже bzip2 или lzma. Пакет будет выглядеть как обычно и устанавливаться как обычно, измениться лишь его размер и скорость установки, в зависимости от архиватора.
Меня заинтересовала идея сжать свой репозитарий, чтобы он меньше занимал место на компакт-диске, чтобы на один диск поместилось больше пакетов. Но для начала, нужно было сравнить производительность этих архиваторов. В интернете полно информации по этому поводу и полно самих тестов и их результатов. Но я решил опробовать все на своей машине.
Тестирование
Был взят, как обычно, архив исходников свежего ядра, упакованный в ".tar".
Размер файла - 337Мб
Процессор на тестируемой машине: Intel Core 2 Duo E2160 1.80ГГц
Оперативная память: 1024Мб
Результаты
Быстрое сжатие (-1):
Сильное сжатие (-9):
Вывод
LZMA все-таки годится для создания пакетов. Он очень медленно сжимает, если использовать сильное сжатие (10 минут, против двух минут у bzip2 и неполной минуте у gzip), зато сжимает сильнее всех архиваторов, да и разница очень ощутима (47Мб против 57Мб у bzip2 и 73Мб у gzip). То есть, пакеты все-таки будут занимать гораздо меньше места. Но, все-таки, скорость распаковки тоже влияет на выбор архиватора. Вот в этом lzma преуспел - он распаковывает почти в три раза быстрее bzip2 и лишь чуть-чуть медленнее gzip.
Одним словом, lzma выиграл по всем параметрам у bzip2, кроме скорости сжатия. И то только при сильном сжатии, при слабом сжатии lzma сжимает быстрее bzip2, но при слабом сжатии почти не заметна разница в размере сжатого файла. GZIP сильно проигрывает всем архиваторам по размеру сжатого файла, но зато он сжимает и распаковывает быстрее всех.
ИМХО, лучше я потрачу несколько часов для перепаковки всех пакетов в lzma, но сэкономлю много места и при этом не проиграю в скорости установки этих пакетов.
В линуксе архиваторы существуют уже давно как часть GNU утилит. Ими сжимается образ ядра, мануалы, пакеты и много чего другого. Они призваны экономить место на носителях данных.
Сейчас, наиболее популярными архиваторами в линуксе являются gzip, bzip2 и сравнительно более новый архиватор - lzma. Поддержка всех этих трех архиваторов уже есть в новом ядре и в некоторых пакетных менеджерах, таких как dpkg. Это значит, что вы можете сжать ядро, чтобы оно меньше занимало места на носителе (удобно для встраеваемых устройств). Так-же, в том же дистрибутиве Ubuntu используются ".deb" пакеты, в которых находятся сжатые файлы (сами бинарники программы, документация и т.п.). В основном, для содержимого ".deb" пакетов используется gzip. Но при создании пакетов, давно можно использовать уже bzip2 или lzma. Пакет будет выглядеть как обычно и устанавливаться как обычно, измениться лишь его размер и скорость установки, в зависимости от архиватора.
Меня заинтересовала идея сжать свой репозитарий, чтобы он меньше занимал место на компакт-диске, чтобы на один диск поместилось больше пакетов. Но для начала, нужно было сравнить производительность этих архиваторов. В интернете полно информации по этому поводу и полно самих тестов и их результатов. Но я решил опробовать все на своей машине.
Тестирование
Был взят, как обычно, архив исходников свежего ядра, упакованный в ".tar".
Размер файла - 337Мб
Процессор на тестируемой машине: Intel Core 2 Duo E2160 1.80ГГц
Оперативная память: 1024Мб
Результаты
Быстрое сжатие (-1):
| Архиватор | Сжатие (время) | Распаковка (время) | Размер сжатого файла | |
| gzip | 0m13.035s | 0m7.899s | 91M | |
| bzip2 | 1m22.186s | 0m22.271s | 69M | |
| lzma | 0m44.433s | 0m12.920s | 66M |
Сильное сжатие (-9):
| Архиватор | Сжатие (время) | Распаковка (время) | Размер сжатого файла | |
| gzip | 0m47.401s | 0m7.102s | 73M | |
| bzip2 | 1m51.064s | 0m28.974s | 57M | |
| lzma | 9m56.781s | 0m10.475s | 47M |
Вывод
LZMA все-таки годится для создания пакетов. Он очень медленно сжимает, если использовать сильное сжатие (10 минут, против двух минут у bzip2 и неполной минуте у gzip), зато сжимает сильнее всех архиваторов, да и разница очень ощутима (47Мб против 57Мб у bzip2 и 73Мб у gzip). То есть, пакеты все-таки будут занимать гораздо меньше места. Но, все-таки, скорость распаковки тоже влияет на выбор архиватора. Вот в этом lzma преуспел - он распаковывает почти в три раза быстрее bzip2 и лишь чуть-чуть медленнее gzip.
Одним словом, lzma выиграл по всем параметрам у bzip2, кроме скорости сжатия. И то только при сильном сжатии, при слабом сжатии lzma сжимает быстрее bzip2, но при слабом сжатии почти не заметна разница в размере сжатого файла. GZIP сильно проигрывает всем архиваторам по размеру сжатого файла, но зато он сжимает и распаковывает быстрее всех.
ИМХО, лучше я потрачу несколько часов для перепаковки всех пакетов в lzma, но сэкономлю много места и при этом не проиграю в скорости установки этих пакетов.
среда, 10 июня 2009 г.
Установка ядра 2.6.30 в Ubuntu
Предисловие (можно пропустить :) )
Есть большое количество способов установить самое свежее ядро в дистрибутивах линукса. Самое популярное из них - это скачивание исходников самого последнего ядра, конфигурирование и компилирование.
Но дистрибутив Ubuntu цениться своей легкостью и удобством. Многие забывают об этом и собирают ядра в этом дистрибутиве из исходников. Конечно, это очень полезный процесс - можно сконфигурировать ядро так, как вам этого хочется, использовать самое главное преимущество линукса - гибкость. Но, как было однажды сказано на linux.org.ru - "Одним движением make install любой дистрибутив превращается в слаку" (После установки софта таким способом из исходников, этот самый софт потом тяжело удалить, обновить или вообще проводить какие-либо операции, то есть исчезает одно преимущество линукса - менеджер пакетов больше не сможет управлять программой, установленной таким способом). Этот недостаток можно решить сборкой из исходников .deb пакета, с помощью некоторых утилит. Но есть способ проще...
Простая установка свежего ядра в дистрибутиве Ubuntu
Разработчики данного дистрибутива сами собирают свежие ядра, дабы радовать пользователей и испытывать эти ядра на этих самых хомячках, то есть пользователях. Пакеты лежат в виде .deb файлах, рассортированных по папкам с версиями ядер, на вот этой странице:
http://kernel.ubuntu.com/~kernel-ppa/mainline/
Собственно, сама установка ядра 2.6.30:
Скачиваем три вот этих файла в любую папку:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-image-2.6.30-020630-generic_2.6.30-020630_i386.deb (~24 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630_2.6.30-020630_all.deb (~8.8 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630-generic_2.6.30-020630_i386.deb (~598 Кб)
Последние два файла нужны в основном для сборки других программ и драйверов, не вошедших в ядро, но при любом раскладе, советую их ставить тоже.
Если у вас 64х битная система, замените в ссылках "i386" на "amd64".
Все скаченные файлы можно теперь установить по порядку, дважды кликнув по ним.
Можно так-же установить их в консоли всего одной коммандой:
На вопрос "что делать с файлом menu.lst" отвечаем, чтобы "установил версию из пакета". Не волнуйтесь, он не заменит целиком старый файл новым, он просто обновит его - добавит все ядра, установленные в вашей системе с параметрами по умолчанию. Если вы изменяли файл "/boot/grub/menu.lst", например, удаляли в нем в параметрах ядра слова "splash", можно просто сделать так, чтобы при любом автоматическом обновлении файла "menu.lst", использовались только ваши параметры. Перед установкой нового ядра, откройте файл "/boot/grub/menu.lst" с правами рута:
Заключение
В общем, это все. Скачать три файла и кликать по ним по два раза. С более новыми ядрами или более старыми с сайта "kernel.ubuntu.com" поступать точно так-же.
Есть большое количество способов установить самое свежее ядро в дистрибутивах линукса. Самое популярное из них - это скачивание исходников самого последнего ядра, конфигурирование и компилирование.
Но дистрибутив Ubuntu цениться своей легкостью и удобством. Многие забывают об этом и собирают ядра в этом дистрибутиве из исходников. Конечно, это очень полезный процесс - можно сконфигурировать ядро так, как вам этого хочется, использовать самое главное преимущество линукса - гибкость. Но, как было однажды сказано на linux.org.ru - "Одним движением make install любой дистрибутив превращается в слаку" (После установки софта таким способом из исходников, этот самый софт потом тяжело удалить, обновить или вообще проводить какие-либо операции, то есть исчезает одно преимущество линукса - менеджер пакетов больше не сможет управлять программой, установленной таким способом). Этот недостаток можно решить сборкой из исходников .deb пакета, с помощью некоторых утилит. Но есть способ проще...
Простая установка свежего ядра в дистрибутиве Ubuntu
Разработчики данного дистрибутива сами собирают свежие ядра, дабы радовать пользователей и испытывать эти ядра на этих самых хомячках, то есть пользователях. Пакеты лежат в виде .deb файлах, рассортированных по папкам с версиями ядер, на вот этой странице:
http://kernel.ubuntu.com/~kernel-ppa/mainline/
Собственно, сама установка ядра 2.6.30:
Скачиваем три вот этих файла в любую папку:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-image-2.6.30-020630-generic_2.6.30-020630_i386.deb (~24 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630_2.6.30-020630_all.deb (~8.8 Мб)
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/linux-headers-2.6.30-020630-generic_2.6.30-020630_i386.deb (~598 Кб)
Последние два файла нужны в основном для сборки других программ и драйверов, не вошедших в ядро, но при любом раскладе, советую их ставить тоже.
Если у вас 64х битная система, замените в ссылках "i386" на "amd64".
Все скаченные файлы можно теперь установить по порядку, дважды кликнув по ним.
Можно так-же установить их в консоли всего одной коммандой:
dpkg -i linux-*-2.6.30*.deb
На вопрос "что делать с файлом menu.lst" отвечаем, чтобы "установил версию из пакета". Не волнуйтесь, он не заменит целиком старый файл новым, он просто обновит его - добавит все ядра, установленные в вашей системе с параметрами по умолчанию. Если вы изменяли файл "/boot/grub/menu.lst", например, удаляли в нем в параметрах ядра слова "splash", можно просто сделать так, чтобы при любом автоматическом обновлении файла "menu.lst", использовались только ваши параметры. Перед установкой нового ядра, откройте файл "/boot/grub/menu.lst" с правами рута:
sudo gedit /boot/grub/menu.lstИ найдите там строчку:
# defoptions=Добавьте туда только ваши личные параметры или вообще удалите все значения, если они вам не нужны. Раскоментировать строчку не надо, она нужна только для автоматического обновления (изменения) этого файла. То есть, приведя эту строчку к такому виду:
# defoptions=noresumeДля всех установленных ядер будут применяться параметр noresume и вам больше не придется редактировать этот файл.
Заключение
В общем, это все. Скачать три файла и кликать по ним по два раза. С более новыми ядрами или более старыми с сайта "kernel.ubuntu.com" поступать точно так-же.
Вышло ядро Linux 2.6.30
Торвальдс сделал мне подарочек на мой день рождения - сегодня зарелизилось новое ядро - 2.6.30))
Изменений много, тупо копировать не будут, дам лишь ссылки:
http://www.opennet.ru/opennews/art.shtml?num=22084 - на русском языке
http://kernelnewbies.org/Linux_2_6_30 - более полный список изменений на английском языке
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро (Торвальдс пока на главной странице не выложил)
http://mirror.yandex.ru/kernel.org/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро с зеркала на яндексе
http://kernel.ubuntu.com/~kernel-ppa/mainline/ - а вот здесь скоро должен появится бинарный пакет с новым ядром. То есть это для тех, кому лень компилить. Пакет от самой убунты и для самой убунты.
P.S.: Скоро буду тестить производительность в сравнении с ядром 2.6.28 (то есть дефолтным).
Изменений много, тупо копировать не будут, дам лишь ссылки:
http://www.opennet.ru/opennews/art.shtml?num=22084 - на русском языке
http://kernelnewbies.org/Linux_2_6_30 - более полный список изменений на английском языке
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро (Торвальдс пока на главной странице не выложил)
http://mirror.yandex.ru/kernel.org/linux/kernel/v2.6/linux-2.6.30.tar.bz2 - ссылка на само ядро с зеркала на яндексе
http://kernel.ubuntu.com/~kernel-ppa/mainline/ - а вот здесь скоро должен появится бинарный пакет с новым ядром. То есть это для тех, кому лень компилить. Пакет от самой убунты и для самой убунты.
P.S.: Скоро буду тестить производительность в сравнении с ядром 2.6.28 (то есть дефолтным).
вторник, 26 мая 2009 г.
Создаем свой мини-дистрибутив линукса
http://www.ibm.com/developerworks/ru/edu/l-embedded-distro/index.html
http://www.ibm.com/developerworks/ru/library/l-linuxboot/
http://www.linuxjournal.com/node/4335/print
http://buildroot.uclibc.org/ http://www.buildroot.org/
http://ru.wikipedia.org/wiki/Busybox
http://en.wikipedia.org/wiki/Busybox
http://www.ibm.com/developerworks/library/l-busybox/
http://www.ibm.com/developerworks/ru/library/l-linuxboot/
http://www.linuxjournal.com/node/4335/print
http://buildroot.uclibc.org/ http://www.buildroot.org/
http://ru.wikipedia.org/wiki/Busybox
http://en.wikipedia.org/wiki/Busybox
http://www.ibm.com/developerworks/library/l-busybox/
воскресенье, 24 мая 2009 г.
Оптимизация загрузки Ubuntu 9.04. Часть 4
По мере накопления информации, буду дописывать 4ю часть, но потом хочу слить все части в одну статью.
Так вот, забыл упомянуть самое главное. Скорость загрузки ОС также напрямую зависит от файловой системы, на которой стоит ОС. Дело в том, что с мелкими файлами лучше работает новая ext4 и старый reiserfs. Собственно, в дистрибутиве больше всего мелких файлов. Поэтому, рекомендую полностью переходить на ext4 - это намного уменьшит скорость не только загрузки ОС, но и саму работу с системой, программами и файлами.
Так-же, можно отключить предварительную проверку разделов жесткого диска во время загрузки ОС. Журналируемые файловые системы уже давно безопасны и проверять их желательно лишь после достаточно долгого использования, после небезопасного выключения компьютера, после глюков, ну и по желанию собственно. Отключать надо в файле "/etc/fstab". Там в конце каждой строчки стоят две цифры. Нам нужна только последняя цифра, она и отвечает за проверку жесткого диска во время запуска ОС. Меняем эту цифру на ноль на нужных файловых системах. И все, больше ничего трогать не нужно.
От половины до двух секунд занимает проверка, выходит ли компьютер из спящего режима или стартует обыкновенно (можете посмотреть по dmesg по ключевым словам resume). Отключить можно просто, добавляем в "/boot/grub/menu.lst" в конец строки с параметрами ядра ("kernel vmlinuz-bla bla-bla-bla") слово noresume.
Так вот, забыл упомянуть самое главное. Скорость загрузки ОС также напрямую зависит от файловой системы, на которой стоит ОС. Дело в том, что с мелкими файлами лучше работает новая ext4 и старый reiserfs. Собственно, в дистрибутиве больше всего мелких файлов. Поэтому, рекомендую полностью переходить на ext4 - это намного уменьшит скорость не только загрузки ОС, но и саму работу с системой, программами и файлами.
Так-же, можно отключить предварительную проверку разделов жесткого диска во время загрузки ОС. Журналируемые файловые системы уже давно безопасны и проверять их желательно лишь после достаточно долгого использования, после небезопасного выключения компьютера, после глюков, ну и по желанию собственно. Отключать надо в файле "/etc/fstab". Там в конце каждой строчки стоят две цифры. Нам нужна только последняя цифра, она и отвечает за проверку жесткого диска во время запуска ОС. Меняем эту цифру на ноль на нужных файловых системах. И все, больше ничего трогать не нужно.
От половины до двух секунд занимает проверка, выходит ли компьютер из спящего режима или стартует обыкновенно (можете посмотреть по dmesg по ключевым словам resume). Отключить можно просто, добавляем в "/boot/grub/menu.lst" в конец строки с параметрами ядра ("kernel vmlinuz-bla bla-bla-bla") слово noresume.
Несколько идей...
Попробовал использовать preload. Но никакого прироста производительности не заметил, скорее наоборот. Но подробно не вникал в этот вопрос. Кому интересно, поставьте в синаптике пакет "preload". Он должен влиять не только на скорость загрузки ОС, но и на вообще скорость работы всех приложений. Если будет хоть какой-нибудь прогресс, дайте знать, попробую вникнуть в ее работу лучше.
Еще есть идея полностью отказаться от использования Initial Ram-Disk (initrd). Тут есть конечно некоторые недостатки, но для галочки просто необходимо попробовать.
Так-же, после изучения кучи систем стартовых скриптов и программ типа /sbin/init, решил написать свою программу, более простую, несовместимую со всеми остальными методами загрузки, но зато быструю и удобную. Совместимость только лишь тормозит прогресс.
Можно еще сделать некое подобие initrd. Сейчас initrd - это костыль в системе. Но что если самые важные части системы, которые не обязательно изменять каждый раз, запаковать в образ squashfs или по подобной технологии. Тут не нужно чрутиться, долго искать положение файлов на файловой системе, можно вообще основные вещи загрузить целиком в память и так далее. Конечно, сложно создавать такой образ, особенно сложно будет оновлять компоненты этой базовой системы.
В общем, пишите свои мысли в комментариях, очень интересно узнать, что вы об этом думаете.
Еще есть идея полностью отказаться от использования Initial Ram-Disk (initrd). Тут есть конечно некоторые недостатки, но для галочки просто необходимо попробовать.
Так-же, после изучения кучи систем стартовых скриптов и программ типа /sbin/init, решил написать свою программу, более простую, несовместимую со всеми остальными методами загрузки, но зато быструю и удобную. Совместимость только лишь тормозит прогресс.
Можно еще сделать некое подобие initrd. Сейчас initrd - это костыль в системе. Но что если самые важные части системы, которые не обязательно изменять каждый раз, запаковать в образ squashfs или по подобной технологии. Тут не нужно чрутиться, долго искать положение файлов на файловой системе, можно вообще основные вещи загрузить целиком в память и так далее. Конечно, сложно создавать такой образ, особенно сложно будет оновлять компоненты этой базовой системы.
В общем, пишите свои мысли в комментариях, очень интересно узнать, что вы об этом думаете.
понедельник, 11 мая 2009 г.
Оптимизация загрузки Ubuntu 9.04. Часть 3.
Убил напрочь свою убунту. Экспериментировал с системой стартовых скриптов и insserv. Пока восстановлю, пока заново разберусь во всем, напишу-ка еще один способ оптимизации загрузки.
Если присмотреться к логам bootchart, то можно увидеть, что скорость загрузки ограничивает винчестер в компьютере. Мало того, что скорость чтения с него не такая уж большая, но еще и файлы, которые запускаются при загрузке с винчестера, размазаны по файловой системе и при загрузке, система должна отыскать их и только потом грузить. То есть, на данный момент все происходит вот так: система ищет файл на винчестере, загружает его, запускает, когда тот завершил свою работу, система ищет следующий файл и так далее. Попробуйте хотя-бы подумать, сколько всего этих файлов. Есть выход из этой ситуации. И называется он - readahead. С этой штукой все выглядит иначе. Перед загрузкой файлов, программа readahead по списку ищет и загружает все загрузочные файлы за один раз, а дальше уже все идет проще - система стартовых скриптов запускает один файл, потом другой и т.д. Без предварительного поиска по винчестеру. Это сокращает время загрузки на очень большой процент (но который постоянно колеблется).
И так, открываем synaptic и ставим там пакет readahead. После чего перезагружаемся, но когда появляется меню выбора ОС (меню grub, если не появляется, то нажмите клавишу Esc, как только появится отсчет на экране), выбираем нашу систему и нажимаем клавишу "e", теперь можно отредактировать параметры ядра. В конце строчки "kernel vmlinuz-xx blablabla" пишем слово "profile" (без ковычек естественно и с пробелом между концом строки и самого слова) и нажимаем клавишу "b". Система будет грузится несколько минут, но в последующие разы, слово profile писать не надо. Эта команда генерирует список всех загружаемых вначале файлов в файл /etc/readahead/boot. В следующий раз, после проделанной операции, система будет грузится еще на пару секунд быстрее.
Пока я восстанавливаю свою систему, можете поискать в интернете информацию и почитать вот эти темы:
insserv, readahead, sreadahead, upstart
Если присмотреться к логам bootchart, то можно увидеть, что скорость загрузки ограничивает винчестер в компьютере. Мало того, что скорость чтения с него не такая уж большая, но еще и файлы, которые запускаются при загрузке с винчестера, размазаны по файловой системе и при загрузке, система должна отыскать их и только потом грузить. То есть, на данный момент все происходит вот так: система ищет файл на винчестере, загружает его, запускает, когда тот завершил свою работу, система ищет следующий файл и так далее. Попробуйте хотя-бы подумать, сколько всего этих файлов. Есть выход из этой ситуации. И называется он - readahead. С этой штукой все выглядит иначе. Перед загрузкой файлов, программа readahead по списку ищет и загружает все загрузочные файлы за один раз, а дальше уже все идет проще - система стартовых скриптов запускает один файл, потом другой и т.д. Без предварительного поиска по винчестеру. Это сокращает время загрузки на очень большой процент (но который постоянно колеблется).
И так, открываем synaptic и ставим там пакет readahead. После чего перезагружаемся, но когда появляется меню выбора ОС (меню grub, если не появляется, то нажмите клавишу Esc, как только появится отсчет на экране), выбираем нашу систему и нажимаем клавишу "e", теперь можно отредактировать параметры ядра. В конце строчки "kernel vmlinuz-xx blablabla" пишем слово "profile" (без ковычек естественно и с пробелом между концом строки и самого слова) и нажимаем клавишу "b". Система будет грузится несколько минут, но в последующие разы, слово profile писать не надо. Эта команда генерирует список всех загружаемых вначале файлов в файл /etc/readahead/boot. В следующий раз, после проделанной операции, система будет грузится еще на пару секунд быстрее.
Пока я восстанавливаю свою систему, можете поискать в интернете информацию и почитать вот эти темы:
insserv, readahead, sreadahead, upstart
суббота, 9 мая 2009 г.
Оптимизация загрузки Ubuntu 9.04. Часть 2.
В продолжение предыдущей статьи, могу добавить еще пару легких советов. В этот раз с консолью возиться не придется:
- Лезем в "Система" -> "Параметры" -> "Запускаемые приложения" и убираем галочки с ненужных сервисов. Например, я лично отключил вот эти службы: Evolution Alarm Notifier, Gnome Login Sound, Gnome Splash screen, Print Queue Applet (у меня принтера нет), Remote Desktop (не пользуюсь удаленным рабочим столом), Update Notifier (обновляться проще вручную, когда самого приспичит), User Folders Update, Visual Assistance (для людей без осложнений со зрением и некоторыми другими недугами - не нужно). Всегда можно вернуть службы назад, поставив обратно галочку.
- "Система" -> "Администрирование" -> "Службы". Тут особо отключать нечего, ну в зависимости от установленного ПО на вашем компьютере. Но если нету на компьютере того-же принтера или блутуса - можно убрать галочки с печати и блутуса, до тех пор, пока не появятся эти девайсы. Так-же можно отключить samba или apache, если вы их устанавливали и пользуетесь только раз в неделю, а не при каждом запуске компьютера (всегда можно будет вернуть автозагрузку обратно или всегда можно загрузить и вручную).
- В synaptic поставьте пакет bum. В меню "Система" -> "Администрирование" появится пункт "BootUp-Manager". Это как-бы дополнение к настройкам служб. Здесь можно отключить чуть больше, чем в стандартных настройках служб. Но будьте осторожны!
Оптимизация загрузки Ubuntu 9.04. Часть 1.
Конечно, скорость загрузки GNU/Linux не играет особой роли, но все-таки, удобней, когда система загружается за несколько секунд, а не минут. Особо неудобно, когда медленно включается ноутбук/нетбук или другое портативное устройство. Попробуем уменьшить время запуска дистрибутива Ubuntu 9.04.
Для начала нужно узнать, за какое время загружается ОС в данный момент, чтобы потом было с чем сравнивать. Для этого, лезем в synaptic и устанавливаем утилиту bootchart. Она при каждой загрузке составляет отчет о загрузке компонентов ОС. Логи она хранит в папке /var/log/bootchart в формате png.
И так, после перезагрузки, можно посмотреть, за какое время система загружается до GDM. Открываем png файл в /var/log/bootchart и смотрим время. Теперь можно приступить наконец к легким путям оптимизации времени запуска ОС. Дело в том, что большинство этих путей уменьшают время всего на секунду - на две, а иногда и того меньше. Но в совокупности - можно сократить время загрузки Ubuntu примерно до 25 секунд (от меню grub до завершения запуска Gnome).
И так, приступим:
Для начала нужно узнать, за какое время загружается ОС в данный момент, чтобы потом было с чем сравнивать. Для этого, лезем в synaptic и устанавливаем утилиту bootchart. Она при каждой загрузке составляет отчет о загрузке компонентов ОС. Логи она хранит в папке /var/log/bootchart в формате png.
И так, после перезагрузки, можно посмотреть, за какое время система загружается до GDM. Открываем png файл в /var/log/bootchart и смотрим время. Теперь можно приступить наконец к легким путям оптимизации времени запуска ОС. Дело в том, что большинство этих путей уменьшают время всего на секунду - на две, а иногда и того меньше. Но в совокупности - можно сократить время загрузки Ubuntu примерно до 25 секунд (от меню grub до завершения запуска Gnome).
И так, приступим:
- Я недолюбливаю заставку при запуске убунты - не так уж и красиво и при этом малоинформативно. Можно без всяких проблем избавиться от нее и сэкономить секунду запуска ОС. В synaptic удаляем пакет usplash и редактируем настройки grub: sudo gedit /boot/grub/menu.lst Находим там строчку с параметрами ядра:
kernel /boot/vmlinuz-2.6.28-12-generic root=UUID=619b888a-ccd8-40b8-a1dc-8ca721829b3f ro quiet splash
и убираем слова quiet и splash. Сохраняем и теперь наслаждаемся подробным и более крутым видом загрузки. - После загрузки ядра, в ubuntu начинает загружаться образ рам-диска (initial ramdisk, initrd). Если распаковать этот образ, можно убедится, что там очень много чего лишнего и распакованный он занимает чуть-ли не 25 мегабайт. Поэтому, желательно пересобрать все initrd-образы в системе только с необходимыми модулями. Но все не так сложно, как кажется. Открываем файл:
sudo gedit /etc/initramfs-tools/initramfs.conf
Находим там строчкуMODULES=most
и заменяем ее наMODULES=dep
Все, теперь надо запустить командуsudo update-initramfs -k all -u
Она пересоберет для всех установленных ядер все найденные образы initrd. В будущем, для новоустановленного ядра, initrd будет генерироваться уже сам с этими параметрами, так что это нужно сделать всего один раз. Теперь файлы initrd будут весить примерно по 3 мегабайта запакованными и по 6-7 мегабайт - распакованными. Это частично сократит время загрузки и при этом не повлияет отрицательно на систему. - У кого двух или более ядерный процессор, можно попробовать использовать параллельную загрузку. Открываем synaptic и ставим пакет insserv. После чего делаем так: sudo gedit /etc/init.d/rc Находим строчку CONCURRENCY=none и заменяем ее на CONCURRENCY=shell Перезагружаемся и проверяем, все-ли в порядке.
Подписаться на:
Сообщения (Atom)