LINUX.ORG.RU
ФорумTalks

[арченовости-день] Поддержка /usr на отдельном разделе


0

1

Привет, потсоны!

Вместе с релизом mkinitcpio 0.8.2 добавили поддержку монтирования /usr из early userspace, в случае если /usr расположено на отдельном разделе. Кто там кричал «хотим фичу, суть такова..», ну вот, теперь она есть и ее надо тестировать.

Чтобы заработало, нужно две вещи:

1) Включить хук shutdown в /etc/mkinitcpio.conf. Он скопирует содержимое initramfs в /run/initramfs в ходе начальной загрузки и добавит небольшой скрипт (ВНЕЗАПНО называющийся shutdown). При выключении, initscripts смонтирует API filesystems в /run/initramfs, переключится на этот новый корень и затем подряд отмонтирует реальные файловые системы.

На момент написания, всё это работает максимально тупо. Не разбираются сложные системы, такие как LVM, и не закрываются шифровальные маппинги. Возможно, это добавится в следующем релизе.

2) Добавить хук fsck в /etc/mkinitcpio.conf. В случае если /usr имеет файловую систему, отличающуюся от файловой системы корня, нужно добавлять его до autodetect. Если вы не добавите этот хук, может случится много грустных вещей (и после этого вы пойдете ныть в толксы что Арча — для красноглазой школоты, и нужно валить на какое-нибудь отродье мамонта типа Debian Stable :). Быть может, в следующем релизе хук станет достаточно умным, чтобы обрабатывать бинарники только из корня и /usr.

Этот хук fsck рекомендуется абсолютно всем, а не только тем, у кого отдельный /usr. Запуск fsck в early userspace означает, что диск может быть проверен до монтирования — поэтому чинить можно без перезагрузки.

При использовании systemd всё должно работать точно так же. Скрипт shutdown игнорируется, а корень не будет перепроверяться из-за наличия сигнального файла, появившегося в /run/initramfs.

(Ответственный за безобразие — Дейв Рейзнер.)

Happy new updates, gentlemen!

★★★★☆

Как это по-человечески, создать проблему, а затем героически её решить.

Artificial_Thought ★★★★ ()

Да здравствует костылестроение, ага.

Между прочим, в когда инициативу федоры обсуждали в рассылке дебиана, один чувак там очень правильно поставил вопрос. Искать лень, пересказываю своими словами:

Почему сейчас есть проблемы с /usr. Потому что udev запускается раньше, чем монтируется /usr. А почему udev запускается раньше? Потому что нужно проинициализировать девайсы для монтирования /usr. Это замкнутый круг.

Давайте представим, что мы в загрузочном скрипте вручную выполнили восход солнца и подняли все устройства, нужные для работы /usr. Теперь мы можем смонтировать /usr и спокойно запустить udev.

Но! ВНЕЗАПНО! Предложенный федорой перенос ответственности за монтировние /usr на initrd ведь делает именно это! Теперь, по их логике, некий скрипт в initrd ответственнен за инициализацию железа до той степени, когда станет возможно смонтировать /usr. Так чем же это отличается от варианта «вручную в загрузочном скрипте, лежащем в /etc»? Ничем не отличается.

Так что предложенный федорой вариант на самом деле не решает ни одной актуальной проблемы. Он просто перекладывает ответственность с больной головы на здоровую: раньше за это отвечала загрузочная логика в корне, теперь её засунули в initrd. Ничего не изменилось.

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

На мой взгляд, этот абсудр дойдёт до своего логического завершения тем, что в initrd станут толкать всё больше и больше кода, и в итоге засунут практически всю загрузочную логику, что сейчас лежит в корне, включая и udev со всеми скриптами. После чего в какую-нибудь «светлую» голову придёт «гениальная» идея: «А давайте не будем засовывать initrd в архив, а разместим как обычную файловую систему на диске». И родится initrd2 — уменьшенная копия initrd, которая грузит initrd, который грузит систему с /usr.

geekless ★★ ()

Я чего-то не понял: это с каких-таких пор /usr отдельным разделом стало вдруг некошерно использовать? УМВР (в мандуриве, в домашнем арче /usr на корне, и лишь /var отдельным разделом).

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

это с каких-таких пор /usr отдельным разделом стало вдруг некошерно использовать?

Так повелел Поттеринг.

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

Интересный вывод, а главное вполне может быть.

DrF ()
Ответ на: комментарий от Komintern

Поттеринг утверждал, что проблемы и так есть.

Deleted ()
Ответ на: комментарий от Komintern

стоп. а раньше что, нельзя было /usr на отдельный раздел выносить?????

Были проблемы с PulseAudio и ещё какой-то фигнёй, которую, кажись, Поттеринг и написал

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

Он сломан из-за udev. PA вообще ни при чем, PA ничего не мешает запустить ПОСЛЕ монтирования /usr.

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

стоп. а раньше что, нельзя было /usr на отдельный раздел выносить?????

У меня на всех более-менее серьёзных машинах /usr на отдельных разделах. Так геморроя меньше и гибкость выше.

Ну а уж упомянутый в теме /var обязан быть на отдельном разделе у всех, кто хоть как-то о скорости системы заботится.

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

Действительно интересно в чем красота /usr на отдельном разделе?

У меня например /home /var / отдельные разделы, /run /dev монтируются в tmpfs. Что я теряю от того что у меня /usr на одном разделе с корнем?

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

Забыл /tmp и /var/lock тоже смотированны в tmpfs. И я говорю про домашнюю систему, но в принципе интересно узнать и про сервера.

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

Ну а уж упомянутый в теме /var обязан быть на отдельном разделе у всех, кто хоть как-то о скорости системы заботится.

Почему?

Deleted ()
Ответ на: комментарий от Behem0th

Что я теряю от того что у меня /usr на одном разделе с корнем?

Возможность быстро и без напрягов (без привлечения всяких LiveCD) поменять файловую систему на более подходящую (или поискать оптимальную), провести полноценную «дефрагментацию мувом», возможность монтировать /usr в R/O, возможность использовать squashfs, и т.д, и т.п.

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

У меня и ext3 фрагментируется

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

Просто про ext4 тезис о нефрагментируемости (или пренебрежимо малой фрагментируемости) особенно часто звучит.

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

Хм преимущества действительно есть но для меня и правда не интересные.

поменять файловую систему на более подходящую

Я уже для себя определился так что когда надумаю менять (будет это не скоро) не проблема один раз заюзать лайвСД

провести полноценную «дефрагментацию мувом»

Корень у меня на SSD

возможность монтировать /usr в R/O, возможность использовать squashfs,

По мне логичнее вынести с корня в отдельный раздел /etc и весь корень смонтировать в R/O.

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

вынести с корня в отдельный раздел /etc

Его же придётся монтировать из initramfs.

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

провести полноценную «дефрагментацию мувом»

возможность монтировать /usr в R/O]

Один я вижу здесь противоречие?

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

Хм преимущества действительно есть но для меня и правда не интересные

Для меня это тоже обычно не на каждый день. Просто систему ставишь обычно на годы. И несколько раз наступив на грабли, потом начинаешь подстилать соломки. Хуже-то не будет :)

Да, правда, важное замечание — отдельный /usr у меня обычно стоит только на машинах с LVM. Чтобы на отдельном физическом разделе — вроде, на данный момент таких машин нет.

По мне логичнее вынести с корня в отдельный раздел /etc и весь корень смонтировать в R/O

Разве такое можно? У меня корень просто отказывается перемонтироваться в R/O.

KRoN73 ★★★★★ ()
Ответ на: комментарий от druganddrop-2

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

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

Ну можно и /usr вынести, и / делать ro. На любых девайсах вида «стоит за тридевять земель и работает годами» это точно лишним не будет.

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

Это понятно. Откуда возьмется фрагментация на разделе, который обычно смонтирован R/O?

Да хоть и не R/O, записи на _нормальный_ /usr обычно нет.

А вот при каждом обновлении системы — начинается прогрессирующая каша.

Тут R/O в двух контекстах. Чисто для защиты, чтобы нечаянно что-то не снести (не практикую) и перевод на лету без перезагрузки в R/O для дефрага мувом (вот это периодически проделываю).

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

Откуда возьмется фрагментация на разделе, который обычно смонтирован R/O?

Теоретически — при обновлении ПО. Практически — её там с гулькин нос будет, этой фрагментации.

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

Но это не на серверах, хотя я не понимаю, зачем там может понадобиться отдельный раздел /usr.

Вот как раз на сервере — особенно актуально. С отдельным /usr его дефраг мувом провести можно целиком удалённо, с одного ssh. А вот с /usr в корне — только с LiveCD, что для удалённой машины без KVM вообще невозможно.

Вот один из моих серверов:

$ df -lTh
Ф. система    Тип     Разм  Исп  Дост  Исп% смонтирована на
/dev/apvg/root
              ext3    5,0G  926M  3,8G  20% /
tmpfs        tmpfs    4,0G  227M  3,7G   6% /tmp
/dev/mapper/apvg-home
              ext4     30G   19G  9,1G  68% /home
/dev/mapper/apvg-usr
              ext4     15G  6,6G  7,5G  47% /usr
/dev/mapper/apvg-var
              ext4    9,9G  2,5G  6,9G  27% /var
/dev/mapper/apvg-var--cache
              ext4    9,9G  172M  9,2G   2% /var/cache
/dev/mapper/apvg-var--lib--mysql
              ext4    9,9G  8,4G  1,1G  89% /var/lib/mysql
/dev/mapper/apvg-var--log
              ext4     20G   10G  8,8G  54% /var/log
/dev/mapper/apvg-var--tmp
              ext4    9,9G  1,1G  8,3G  12% /var/tmp
/dev/mapper/apvg-var--www
              ext4     20G   14G  5,4G  72% /var/www
/dev/sdb4     ext4    895G  349G  501G  42% /data

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

А вот при каждом обновлении системы — начинается прогрессирующая каша.

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

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

Практически — её там с гулькин нос будет, этой фрагментации.

Через пол-года — год регулярных обновлений дефраг мувом придаёт системе просто вторую жизнь :) Я когда-то цифры по работе ldconfig приводил, время работы в разы ускоряется, не на проценты даже.

Как раз, при обновлении /usr происходит наихудший сценарий — перезаписывается (другой длиной) уйма мелкий файлов.

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

При обновлении системы создаются новые файлы, которые потом переименовываются

Они мелкие. При удалении старых образуется море мелких дырок.

Да, если не понятно, я почти не разделяю фрагментацию файлов и фрагментацию пустого пространства. Они одинаково паршиво влияют на производительность.

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

наихудший сценарий — перезаписывается (другой длиной) уйма мелкий файлов

Вообще-то, не перезаписываются. Переименовываются.

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

Разве такое можно? У меня корень просто отказывается перемонтироваться в R/O.

GotF

Его же придётся монтировать из initramfs.

Я таким не когда не страдал так что тонкостей не знаю, просто где то видел такой совет и он мне показался логичнее чем уср на отдельном разделе. Может я действительно не прав.

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

А вот при каждом обновлении системы — начинается прогрессирующая каша.

Я не знаю, как там в гентах, но в дебиане полный dist-upgrade не изменил состояние фрагментировасти /usr ни на грамм.

GotF ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.