LINUX.ORG.RU

Для Fedora 17 утверждён план по переносу компонентов из корня в /usr и переход на Btrfs

 , ,


0

3

После обсуждения идеи переноса части компонентов корневой системы в /usr и объединения /sbin и /bin принято решение об утверждение планов по реализации первой идеи. Вторая идея одобрения не нашла. Обновленная структура корня будет выглядеть приблизительно следующим образом:

  • /usr - установленная система; общедоступно; возможность монтирования в режиме только чтения;
  • /etc - конфигурационные данные; локально;
  • /var - долговременные данные; локально;
  • /run - переменные данные; локально; обязательно использование tmpfs;
 /
 |-- etc
 |-- usr
 |   |-- bin
 |   |-- sbin
 |   |-- lib
 |   `-- lib64
 |-- run
 |-- var
 |-- bin -> usr/bin
 |-- sbin -> usr/sbin
 |-- lib -> usr/lib
 `-- lib64 -> usr/lib64

О преимуществах данного решения можно подробнее прочитать в предыдущей новости.

Так же принято решение об очередной попытке перехода на Btrfs в качестве основной ФС. По сравнению с прошлым планом дополнительно заявлено о решении использовать стандартные для Btrfs механизмы управления томами, вместо LVM, и организации RAID.

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

Подробности:

О переходе на Btrfs

>>> О переносе компонентов из корня в /usr

★★★★★

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

plm> Вообще куча народу то тут, то там критиковала SysVinit, причем по делу, и вот, когда наконец-то был написан правильный менеджер загрузки

До... Офигенно правильный - не позволяет грузиться, когда /usr на отдельном разделе. А то, что федорщики сейчас делают - это как ампутация ноги при порезе стопы. Хотя нет - обеих ног. А чтобы ходить - держи костыли.

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

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

С ФС - да. А так федора разрабатывается с одной единственной целью - тестирование всего нового, а не обязательное доведение до ума. Именно для этого федора и создавалась.

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

Ну... Есть ещё HURD, kFreeBSD, ARM, MIPS, Alpha, IA-64, ...

Так что это ещё сравнительно короткие названия.

Quasar ★★★★★
()

Именно так создается видимость работы и прогресса.

//Не нужно. Ни «идеи» федоровцев, ни сама федорка, ни разрабы ее.

partyzan ★★★
()

старые /lib* и /bin то хоть останутся в виде симлинков?
а то старый софт, думаю, будет очень рад покидаться какашками :3

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

Ты дальше URL'a видимо не читал.

Интереса ради сходил почитал. И ещё больше убедился, что идея объединения /usr с корнем - бред. Они сваливают всю вину на udev, но так и не отвечают, почему это /usr при загрузке не был примонтирован до запуска проблемных правил udev.

Это во-первых.

Во-вторых, там утверждается, что всё-равно базовая система не запустится без /usr'а, потому как куча софта не запустится(udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth). А теперь объясните мне кто-нибудь, зачем мне запускать все эти свистелки, если мне пришлось бутаться в safe-mode в один только корень? Если уж при загрузке не монтируется /usr, значит что-то не так в системе и как раз мне нужен минимальный корень, чтобы это «что-то не так» починить. С их вариантом, я лишён такой возможности.

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

Они сваливают всю вину на udev, но так и не отвечают, почему это /usr при загрузке не был примонтирован до запуска проблемных правил udev.

Потому что выполнение udev начинается после монтирования корневой ФС, но до монтирования остальных разделов. Их просто нельзя примонтировать - /dev/ ещё нет.

Если уж при загрузке не монтируется /usr, значит что-то не так в системе и как раз мне нужен минимальный корень, чтобы это «что-то не так» починить. С их вариантом, я лишён такой возможности.

Для этого можно использовать initramfs. Хотя, лично я считаю, что проще вообще грузить какой-нибудь riplinux, в / не всегда удаётся поместить всё, что может понадобиться для восстановления.

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

Есть куда более адекватные способы оптимизации загрузки и без использования systemd.

Скорее пиши об этом федоровцам, а то мужыки-то и не знают.

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

Потому что выполнение udev начинается после монтирования корневой ФС, но до монтирования остальных разделов. Их просто нельзя примонтировать - /dev/ ещё нет.

И каким же образом тогда грузится моя гента, в которой /usr на отдельном разделе? Почему-то openrc с этим справляется без проблем. initrd я не использую, потому как, имхо, это костыль бесполезный.

Для этого можно использовать initramfs. Хотя, лично я считаю, что проще вообще грузить какой-нибудь riplinux, в / не всегда удаётся поместить всё, что может понадобиться для восстановления.

И вот, спрашивается, зачем мне дополнительно собирать initramfs, если и без него всё работает? Костыль же, в чистом виде.

shell-script ★★★★★
()

Не надо так наезжать на автора новости за перевод - он делом занялся и новость запостил, спасибо надо сказать. Для native englishmen есть ссылки на оригиналы. Хотя по-честному переводить все слово в слово не есть хорошо, нужно было сделать описательный перевод.

ins3y3d ★★★★★
()

Fedora продолжает неприятно удивлять..

neocrust ★★★★★
()

Зашел с утра на ЛОР, а тут такое...

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

А если я не хочу использовать initrd, это же бред.

Зачем урезать функционал того, что уже работает почти двадцать лет ?

kostik87 ★★★★★
()
Ответ на: комментарий от ls-h

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

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

Да я перевёл-то только про структуру часть. Остальное сам писал.

daemonpnz ★★★★★
() автор топика
Ответ на: комментарий от ls-h

пользователю нечего делать дальше ~ и /media, ему и знать о системных файлах не надо

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

в опенсорсе меритократия, и принимают идеи просто за то, что они хорошие.

в двух словах, если не сложно: для чего нужен перенос части компонентов корневой системы в /usr?

Rastafarra ★★★★
()
Ответ на: комментарий от shell-script

И каким же образом тогда грузится моя гента, в которой /usr на отдельном разделе? Почему-то openrc с этим справляется без проблем. initrd я не использую, потому как, имхо, это костыль бесполезный.

Не знаю, как грузится твоя гента, но мой дебиан с отдельным /usr и systemd тоже грузится без проблем. Как и написано в статье, systemd тут не при чём.
У меня udev не так сильно зависит от /usr - всего лишь не проставляются ID_MODEL_FROM_DATABASE и ID_VENDOR_FROM_DATABASE у pci- и usb-устройств. Как написано в статье, «If these rules fail udev will proceed with the next one», так что грузиться оно грузится. Однако, «later on applications will then not properly detect these udev devices or features of these devices». Я не сталкивался с косяками, связанными с отсутствием этих переменных, но, например, 78-sound-card.rules на основании ID_MODEL_FROM_DATABASE определяет, с чем имеет дело - с микрофоном, наушниками или гарнитурой. Это вполне может вылиться в некорректно работающую алсу.
Так что, повторюсь, systemd тут не при чём, он всё исправно грузит. Проблемы могут возникать в других местах.

И вот, спрашивается, зачем мне дополнительно собирать initramfs, если и без него всё работает? Костыль же, в чистом виде.

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

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

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

Как связаны установка каждой софтины в свой отдельный каталог и статическая линковка?

Laz ★★★★★
()

Хотел было выразить своё мнение по данному вопросу, но взглянув на удалённые могу сказать только одно:
«Всем радоваться 5 минут!»

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

в двух словах, если не сложно: для чего нужен перенос части компонентов корневой системы в /usr?

Изначально речь идёт о том, что схема с маленьким / «на всякий случай» и большим /usr изжила себя, поэтому выносить /usr на отдельный раздел нет смысла. А раз оно всё теперь на одном разделе, почему бы и не объединить /bin и /usr/bin?

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

речь идёт о том, что схема с маленьким / «на всякий случай» и большим /usr изжила себя

Но почему?

У меня и /, и /usr, и /home на разных разделах. /usr/pkgsrc тоже хочу в отдельный вынести

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

что с ней не так?

Сказано же - изжила себя. Примите истину, дарованную вам свыше...

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

У меня и /, и /usr, и /home на разных разделах. /usr/pkgsrc тоже хочу в отдельный вынести

У меня тоже / гигабайтный, остальное отдельно, но вот зачем я это делал, я не помню. Подозреваю, что по привычке :) Вообще, идея в том, что в случае проблем с /usr можно загрузиться в / и починить его, но что-то я не припоминаю, когда это мне хоть когда-то помогло. Проще было загрузиться в riplinux, в котором по максимуму собраны утилиты для решения подобных проблем.

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

Причин полно же - отдельное ro, быстрее файлчек, и тд и тп

/usr в ro? Вариант, хотя, лично я не знаю, зачем это нужно. Файлчек по идее у всех фс происходит в одно и то же время - в нормальных условиях они монтируются одновременно. Использование разных фс для корня и для /usr в целях оптимизации? Ну, может быть. Что-то ещё придумать - затрудняюсь.

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

А если грузиться не с чего? Нет сидирома, мать не умеет с usb? Да или просто под рукой нет образа, а на сервере, который интернеты даёт, после непланового ребута побилась фс и он не может примонтировать часть разделов?

Это реальный случай из жизни, когда меня спасла загрузка в корень, оттуда я полечил другие разделы, потом смог загрузиться в полноценную систему и дальше уже спокойно работать. Теперь, если из-за сбоя посыпется фс, что товарищи разработчики прикажут мне делать?

shell-script ★★★★★
()
Ответ на: комментарий от Laz

Вопрос в том, что с ней так? Другими словами, накой оно надо?

при таком подходе надо оставить один / на весь lvm. почему так не делают?

Rastafarra ★★★★
()
Ответ на: комментарий от shell-script

И вот, спрашивается, зачем мне дополнительно собирать initramfs, если и без него всё работает? Костыль же, в чистом виде.

а теперь представь что не все собирают монолитное ядро с вкомпиливанием всего и вся.

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

1) Сетевая загрузка

/usr на nfs? Или / на nfs? В любом случае, я думал, мы тут локалхосты админим, сетевая загрузка - это уже несколько иного уровня задача.

2) Быстрые разделы SSD

А насколько существенной, по-вашему, будет разница в скорости, если мы отделим /usr от / ? Точных цифр у меня, конечно, нет, но подозреваю, что от / большинству нужен только /etc, редкие почитывания которого вряд ли серьёзно скажутся на производительности, если он будет на одном разделе с /usr.

Laz ★★★★★
()

linux is to be hip again!

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

при таком подходе надо оставить один / на весь lvm. почему так не делают?

На том, что ставлю заново, я делаю именно так.

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

У меня на десктопе ядро чисто под железо и около 20-ти модулей, вынесенных из него.

На серверах стандартные debian'овские ядра с кучей модулей. initrd в grub'е руками отключал после установки. И всё нормально.

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

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

У меня в initramfs есть fsck, оттуда я лечу другие разделы (и корень тоже могу подлечить, если что). А больше ничего особенного отдельный корень не умеет. Вот у меня другая история есть - я очистил таблицу разделов. И как мне тут отдельный корень помог бы? Даже если бы я смог в него загрузиться, testdisk всё равно лежит на /usr. В общем, в случаях серьёзнее «после непланового ребута побилась фс и он не может примонтировать часть разделов» от отдельного корня толку никакого.

Laz ★★★★★
()
Ответ на: комментарий от shell-script

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

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

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

Файлчек по идее у всех фс происходит в одно и то же время

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

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

сетевая загрузка - это уже несколько иного уровня задача.

Т.е. отныне «Федорино горе» становится непригодно для изготовления офиса на терминалах с сетевой загрузкой?

БРАВО! БРАВИСИМО!

(Туда ему и дорога... Не можешь ср..ь - не мучай .опу.)

что от / большинству нужен только /etc

/lib, /boot, /bin, /sbin - загрузка системы и подгрузка модулей.

sergv
()
Ответ на: комментарий от reader

читатель помни информация в википедии ВСЕГДА является субьективным мнением автора статьи!

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