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)
Ответ на: комментарий от unikum

Systemd, теперь это. Хоть Федора и экспериментальный дистрибутив, но, тем не менее, всё ранво не понятно зачем зачем такие кардинальные перемены.

systemd очень тепло принят техническими специалистами, в т.ч. и из embedded-отрасли.

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

systemd очень тепло принят техническими специалистами, в т.ч. и из embedded-отрасли.

«А половина разрабов туда пришла с венды! А по второй половине венда плачет!» (C) Лесь Rephrased

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

«А половина разрабов туда пришла с венды! А по второй половине венда плачет!»

Да откуда-бы ни пришли. Во-1 голос разработчиков всегда громче коллективного голоса анонимных аналитиков, а во-2 в опенсорсе меритократия, и принимают идеи просто за то, что они хорошие.

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

Да откуда-бы ни пришли. Во-1 голос разработчиков всегда громче коллективного голоса анонимных аналитиков, а во-2 в опенсорсе меритократия, и принимают идеи просто за то, что они хорошие.

Мальчик, ты меритократию с диктатурой попутал.

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

Мальчик, ты меритократию с диктатурой попутал.

Ну а когда Леннарт стал диктатором? И кто его таким сделал?

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

Не корми троллей. Они даже не в теме.

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

Ну а когда Леннарт стал диктатором? И кто его таким сделал?

Ещё со времён avahi и pulse audio. На второй вопрос ответить не так-то просто. Видимо, связи.

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

Видимо, связи.

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

Ok
()
Ответ на: комментарий от anonymous

Видимо, связи.

Ну само собой - узнаю собрата-россиянца. Заговор, взятки, связи, блат, знакомство.

То-то местные аналитики с изумлением узнают, что коммьюнити их уютных дистров уже давно обсуждают то, как включить компоненты и фичи, разрабатываемые в Fedora. Походу аналитики ЛОРа настолько оторвались от реальности, что совершенно не понимают происходящего вокруг, отчего всё проклинают и валят на тиранию Леннарта.

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

Они вне коммьюнити. Российское линукс-комьюнити — это засилье тугих индивидуалистов-консерваторов. Но поезд проедет, я гарантирую это.

oguretz
()
Ответ на: комментарий от myhand

я бы даже сказал - горячо. burn it

Это неправда. Например, на недавнем «Embedded LinuxCon Europe 2011» Koen Kooi, инженер Nexas Instruments, представлявший проект Angstrom Linux в своем докладе сообщил, что благодаря systemd ему удалось запустить систему на beagleboard за 1 секунду (с помента окончания загрузки ядра, до запущенного bash-а, в обычном angstorm дистрибутиве - т.е. были стартованы все обычные для angstorm сервисы).

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

Вам уже написали правильные вещи про подобных «разработчиков».

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

Ну нашел мужик решение своей маленькой проблемы - с чего вдруг оно единственное и лучшее? Может вполне имело смысл переписать скрипты, может использовать еще какую-то альтернативу sysvinit.

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

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

Пока, наверное, презентаций больше и правда нет - systemd слишком молод.

Может вполне имело смысл переписать скрипты, может использовать еще какую-то альтернативу sysvinit.

Переписывать скрипты очень плохо с т.ч. производительности. Например, при старте дистрибутива общего пользования, происходит от полутора до двух тысяч запусков мелких утилит, которые производят шаблонные действия (поискать pid, погрепать вывод процессов и т.п.). Все типичные паттерны запуска демона надо вынести в отдельный процесс - это правильно с т.з.Юникс-фэй (и это то, о чем давно говорили, почти с самого начала широкого распространения кучи костыликов на шелл-скриптах, в качестве системы первоначальной загрузки).

Вообще куча народу то тут, то там критиковала SysVinit, причем по делу, и вот, когда наконец-то был написан правильный менеджер загрузки, внезапно появились тучи постов с возражениями и неприятием на исключительно эмоциональном уровне. Самое удивительное, что кучка плохоньких костыликов сразу-же стала неким эталоном загрузки Юникса.

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

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

fixed

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

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

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

Какой еще «дистрибутив общего пользования»? У Вас embedded система - или уже успели потерять контекст?

Вообще куча народу то тут, то там критиковала SysVinit, причем по делу

Критики никто не отменяет. Более того, народ наплодил кучу куда более интересных решений, чем systemd.

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

Может проблема в том, что кто-то излишне активно стремится посчитать его «правильным»? Кстати, сугубо на эмоциональном уровне.

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

Функционал _уже_ выглядит, мягко говоря - расплывчатым. И конца-края этому не видно. Знаете, только из-за этого - восторгов я бы поубавил.

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

Некоторые энтерпрайзные специалисты тепло примут любую вещь, которая превращает линукс в винду.

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

systemd очень тепло принят техническими специалистами, в т.ч. и из embedded-отрасли.

Это что-то в духе get the facts

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

plm> systemd очень тепло принят техническими специалистами, в т.ч. и из embedded-отрасли.

То есть специалисты на systemd наделали тёплую кучу?

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

plm> Ну а когда Леннарт стал диктатором? И кто его таким сделал?

Так Поттеринг не диктатор - он просто сумасшедший.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Насколько я знаю, на федоре обкатывают новые идеи, лично я бы не стал ставить её офисным работникам. Но тем не менее, в случае с сетевой загрузкой какой профит от разделения / и /usr?

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

У нас есть два супермегабыстрых ssd, на одном /, на другом /usr. / используется, когда происходит «загрузка системы и подгрузка модулей», /usr плюс немного /etc всё остальное время. В чём профит?

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

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

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

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

есть такое понятие: «гибкость». говорят лялих ей славится. врут?

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

есть такое понятие: «гибкость». говорят лялих ей славится. врут?

Леннарт Поттеринг: Гибкость. Мы запретим ее.

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

Но тем не менее, в случае с сетевой загрузкой какой профит от разделения / и /usr?

Мало количество памяти на внутренней FLASH. Весь хлам не влезет.

У нас есть два супермегабыстрых ssd, на одном /, на другом /usr

А, в случае с сервером и ОБЯЗАТЕЛЬНЫМ зеркалированием дисков, по деньгам - спина сильно не заболит?

Для тех, кто на бронепоезде: 1) SSD обрабатывает на порядки большее количество запросов в секунду. 2) Это очень хорошо для ускорения загрузки сервера и ускорения критических сервисов (DB, например). Вынесение / и /var/(db|lib)/(mysql|mrtg) на два отдельных раздела SSD даст просто чудесный прирост производительности. 3) SSD большого объема - безумно дороги.

Теперь как вывод:

на федоре обкатывают новые идеи, лично я бы не стал ставить её офисным работникам.

Теперь ее нельзя ставить ни офисным работникам, ни на сервера, ни на эмбедед...

Отсюда вопрос: Кому она ТЕПЕРЬ вообще всралась, кроме ее разрабов и гномофилов???

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

Мало количество памяти на внутренней FLASH. Весь хлам не влезет.

А что это вы там размещаете на внутренней FLASH? У меня при сетевой загрузке никаких проблем с внутренними FLASH не возникало.

Для тех, кто на бронепоезде: 1) SSD обрабатывает на порядки большее количество запросов в секунду. 2) Это очень хорошо для ускорения загрузки сервера и ускорения критических сервисов (DB, например). Вынесение / и /var/(db|lib)/(mysql|mrtg) на два отдельных раздела SSD даст просто чудесный прирост производительности. 3) SSD большого объема - безумно дороги.

То есть, на ssd у нас будут только / и /var/db? И / нужен, чтоб ускорить загрузку (ежечасный ребут очень долго проходит)? А /usr отделим, потому что на / мало места? Ну, не вижу никаких проблем.

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

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

понятно, спасибо за конструктивный диалог.

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

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

Пока лысый дядя с штрихкодом на затылке не посетит Поттеринга - это бесполезно.

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

А что это вы там размещаете на внутренней FLASH? У меня при сетевой загрузке никаких проблем с внутренними FLASH не возникало.

при разработке, например, куда козырнее бутиться по сети.

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

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

Нет никакого «на всякий случай». Корень - базовая система. /usr - расширенная, грубо говоря. Так намного проще, удобнее и логичнее.

Laz> поэтому выносить /usr на отдельный раздел нет смысла.

А если внезапно захотелось завести /usr на другом разделе? А то и винчестере. Что делать? Посылать матюками Поттеринга? Нет - просто пойти и прирезать его.

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

Laz> Вообще, идея в том, что в случае проблем с /usr можно загрузиться в / и починить его, но что-то я не припоминаю, когда это мне хоть когда-то помогло.

Идея не в этом, а в гибкости. Отдельную ФС можно вынести на отдельное устройство, которое более для неё подходит. Поттеринг же по своей непрошибаемой тупости всё это отрицает. Не хочется ему, видите ли, код писать нормальный и предлагать нормальные технологии - вместо этого он жопой стучит по клавиатуре и пишет говнокод.

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

registrant> я бы так не сказал

У тебя медицинское образование? Или так, делитантством занимаешься?

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

А что это вы там размещаете на внутренней FLASH? У меня при сетевой загрузке никаких проблем с внутренними FLASH не возникало.

И его при каждом обновлении пакетов из /usr переливать на ВСЕ терминалы?

(У меня сетевой загрузки НЕТ. Просто мысли)

То есть, на ssd у нас будут только / и /var/db? И / нужен, чтоб ускорить загрузку (ежечасный ребут очень долго проходит)? А /usr отделим, потому что на / мало места? Ну, не вижу никаких проблем.

1) Ежечасный ребут НЕ НУЖЕН. Нужно минимальное время простоя. 2) ЕСЛИ все слить в одну помойку на /usr, то ускорения загрузки не будет.

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

при разработке, например, куда козырнее бутиться по сети.

Не спорю. Только причём здесь внутренний FLASH?

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

Идея не в этом, а в гибкости. Отдельную ФС можно вынести на отдельное устройство, которое более для неё подходит.

Да, точно, можно вынести, например, /etc на отдельное устройство с reiserfs - там у меня куча мелких файлов. Сейчас этим и займусь, ведь sysvinit писал не поттеринг, с этим никаких проблем не будет.

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

registrant> а почему вы спрашиваете?

А почему Вы отвечаете вопросом на вопрос? Вы антисемит?

registrant> я вас лечить не собираюсь, так констатирую факт

Не удосужитесь ли Вы привести источник, откуда почерпнули то, что называете фактом?

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

С инертностью мышления быд...масс бороться подчас непросто. Забейте на это. Через пару лет текущими нововведениями Fedor'ы будут пользоваться многие из тех, с кем Вы сейчас полемизируете. Просто до них пока ещё не дошло, что для них прогресс.

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

И его при каждом обновлении пакетов из /usr переливать на ВСЕ терминалы?

Я, честно говоря, вообще не понял, про какой такой внутренний FLASH идёт речь и зачем он нужен при сетевой загрузке. У меня по сети монтируются как /, так и всё остальное, при обновлении на ВСЕХ терминалах изменения сразу же видны, никаких внутренних FLASH нет. Может, я чего-то не знаю про сетевую загрузку, и у меня на самом деле ничего не работает?

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

Laz> Да, точно, можно вынести, например, /etc на отдельное устройство с reiserfs - там у меня куча мелких файлов.

Твоё дело. Только передёргиваешь тут ты.

Laz> Сейчас этим и займусь, ведь sysvinit писал не поттеринг, с этим никаких проблем не будет.

Где я о sysvinit писал? Зачем ты сюда sysvinit приплетаешь?

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

Не удосужитесь ли Вы привести источник, откуда почерпнули то, что называете фактом?

я бы с удовольствием, но там для людей читающих. как найду с картинками всенепременно оповещу

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

Просто до них пока ещё не дошло, что для них прогресс.

А может просто упоротые путают регресс и прогресс?

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

Может быть, конечно =)

А может быть, что упоротые просто постят бесполезные сообщения на ЛОР'е.

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

Я всегда поддерживал идею давать в качестве капчи два абзаца текста и вопрос на их содержание.

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

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

Вот, ты тормоз. Сказали же, про монтирование по сети /usr.

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