The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В Fedora рассматривается предложение по переносу всех исполн..., opennews (ok), 01-Ноя-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


66. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Аноним (-), 01-Ноя-11, 23:56 
> Лично я не вижу никаких причин делать корень автономным от /usr.

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

В новой схеме:
/ не работает - пофигу, останемся с тем, что нам скрипты из initrd по-быстрому сляпали, главное, /usr-то есть. А конфиги - хрен с ними, сейчас бы починиться.
/usr не работает - сосем лапу и ищем загрузочный сидюк/флешку.

Итак, минусов не видать. А вот плюсы, описанные в новости (например, возможность делать кучу компов с общим /usr), весьма вкусны.

Ответить | Правка | Наверх | Cообщить модератору

92. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudioemail (ok), 02-Ноя-11, 00:48 
В старой схеме была возможность запихать /, /etc и ещё чего-нить на CF карту и физически щёлкнуть на ней переключатель в RO (переключая в RW только в случае обновления или изменения конфигов ручками) то терь обломайтесь по определению. Да да иногда и такое нужно.
Вот такая вот схема.
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

113. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudioemail (ok), 02-Ноя-11, 01:35 
> ... это стало еще проще и удобнее (отдельно рулится RO на конфиги
> - /, отдельно на обновления - /usr).

Вы перечитайте что я пишу. Базовая система вместе с ядром и конфигами и ещё парой вещей лежит на RO (физически RO) флэше.

> Чего-чего? А если подумать?
> Вы вообще понимаете суть предлагаемых изменений, или сразу бросились обсуждать, прочитав
> лишь заголовок?

Я то прекрасно понимаю. Прочитайте ещё разок о чём я говорю.

Ответить | Правка | К родителю #156 | Наверх | Cообщить модератору
Часть нити удалена модератором

122. "В Fedora рассматривается предложение по переносу всех исполн..."  +2 +/
Сообщение от sfstudioemail (ok), 02-Ноя-11, 01:52 
> Ну если вы все прекрасно понимаете, то объясните мне, как именно обсуждаемые
> изменения помешают изложенной вами схеме.

Тем что теперь на флэш мне придётся переть over гигабайт вместо сотни метров.

Если что у себя в Wive-NG-RTNL использую именно такую схему как озвучивают федоровцы. Причём изначально. И уже всё опробавно и проверено.

Для встраиваемых решений где всё упихано в 4-8Мб флэша одним разделом сиё оправдано.

Для реально работающих у меня решений описанных выше (CF Card 128-256Мб) с новой схемой это становиться невозможно или как минимум бесполезно. Ибо все сервисные тулзы аля fsck окажуться в одной помойке с ещё овер гигабайтом софта. В итоге придётся переть всю эту помойку на CF где оно нафиг не нужно, либо забыть о такой схеме в принципе. Тот же бардак
как я понял ожидает и библиотеки.

Продемонстрируйте где ошибся, желательно без теоритезирования на живой конфигурации.

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

Ответить | Правка | К родителю #268 | Наверх | Cообщить модератору
Часть нити удалена модератором

132. "В Fedora рассматривается предложение по переносу всех исполн..."  +3 +/
Сообщение от sfstudioemail (ok), 02-Ноя-11, 02:57 

> Всем бинарникам и либам - что ж, придется тащить весь /usr,а вы
> как думали?

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

Ответить | Правка | К родителю #284 | Наверх | Cообщить модератору
Часть нити удалена модератором

143. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudioemail (ok), 02-Ноя-11, 03:51 
> Простите, не понимаю сути ваших претензий. Вы считаете, что некоторые бинарные файлы
> бинарнее других, и поэтому на них надо ставить RO, а на
> остальные - не надо?

1) Я считаю что базовая система включая ядро, glibc модули ядра, утилиты восстановления должны лежать в RO и ни при каких условиях недопустима даже теоретическая возможность модификации или подмены например одного из модулей ядра (кстати это требования прописаны во внутренних  документах и более чем логичны).

2) Я считаю что взлететь и получить тот же fsck я должен независимо от живости всего остального.

3) Я решаю вполне определённые задачи и они решаются штатными средствами которые предполагается выкинуть.

>Что ж, никто не запрещает вам наплодить
> кучу каталогов и файловых систем, раскидать по ним файлы, прописать их
> в PATH и считать эту схему очень удобной :)

Ой не смешите.
1) Удобство далеко не всегда основной критерий (мы не о локалхостах говорим однако)
2) Ничего плодить не нужно, всё что нужно предусмотрено FHS который предлагается изувечить


> Но людям с не столь извращенным мышлением удобнее сортировать по более простым
> критериям - "здесь бинарники, здесь конфиги, а здесь - логи".

Ну дык никто не мешает им слить всё в кучу и наплодиь симлинков =)) Ну или на крайний случай уйти назад в винду =)

Ответить | Правка | Наверх | Cообщить модератору

149. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от sfstudioemail (ok), 02-Ноя-11, 04:18 
> То есть, вы полагаете, что
> а) ядро и glibc нельзя обновлять ни при каких обстоятельствах
> б) а на все остальные бинарники пофиг - пусть их правит кто
> хочет

Вы вообще читаете что я пишу? О обновлении сказано выше было. Будьте внимательнее.

> Это вам может гарантировать только live-носитель.

Это прекрасно гарантирует CF карта в RO а надо будет 10ть CF карт которые на лету заменяются (да да вместе с корнем, всё давно написано и отлажено).

> Не знаю, какие задачи вы там решаете. А вы упорно не хотите
> говорить.

Не имею права.

> Да я уже понял, что для вас основной критерий - чтобы правой
> щекой через левую пятку :)

Когда будете на моём месте вот тогда и будете рассуждать. Пока советую воздержаться от критики. Вы просили пример который не вписывается в то что творят федогористы - я привёл. Не нравиться? Ну эт ваше личное дело. Я для себя поставил ещё одну галочку "против" федогоря.

> Ага, а автомобиль - это жестоко изувеченная карета.

Не передёргивайте. На мой взгляд автомобиль это FHS. А вот федогоревцы из него пытаются сделать не то карету не то телегу.

> Судя по вашим критериям "привальной организации", идти на винду стоит именно вам.
> Там тоже любят творить фигню, объясняя это невнятными выкриками.

О как, т.е. FHS фигня? Вы бы поменьше бы чепуху бы пороли. Поймите уже что мир гораздо сложнее чем вам кажется и задач гораздо больше нежели хотелось бы. В данном случае я ещё раз говорю, устраивать мешанину из стройной FHS на мой взгляд полная дурость и привнесёт лично мне и людям решающим подобные задачи больше проблем нежели пользы.

Там где такой подход оправдан он давно мной используется (см Wive-NG). Так что не надо тут всех под винду с их "мы все равны не дать не взять" грести.

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

Хочется поспорить - значитхватит теоретизировать и начните применять подход который вы так рьяно защишаете. И не только на локалхосте или говнороутерах.

В общем смысла дальше флудирастить нет ибо работать нужно. Через годик-два посмотрим что из этого всего вышло. Благо я сильно в сомнениях что такой подход переймут все остальные (надеюсь этого не будет, точнее более чем уверен).

Ответить | Правка | Наверх | Cообщить модератору

181. "В Fedora рассматривается предложение по переносу всех исполн..."  +1 +/
Сообщение от agent_007 (ok), 02-Ноя-11, 11:47 
> Не имею права.

достаточно сказать волшебные слова "embedded development". подробности ни к чему :)

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

239. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от sfstudioemail (ok), 02-Ноя-11, 17:21 
> достаточно сказать волшебные слова "embedded development". подробности ни к чему :)

Какраз встройка тут не причём в стройке см выше.

Ответить | Правка | К родителю #181 | Наверх | Cообщить модератору

276. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorinemail (ok), 03-Ноя-11, 03:28 
> Вы вообще читаете что я пишу?

Он демагог и не за тем пришёл, не трать время.

Ответить | Правка | К родителю #149 | Наверх | Cообщить модератору

206. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorinemail (ok), 02-Ноя-11, 14:18 
> Итак, минусов не видать.

А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/ по сравнению с размером /.  Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.

Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

258. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Zulu (?), 02-Ноя-11, 22:06 
> А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/ по сравнению с размером /

Строго похрен.
Много ты видел систем где /usr находится на отдельном физическом носителе по сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.

> Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.

А что это имеет общего с объединением / и /usr? Или (испуганно) кто-то имеет отдельный /usr, но неотделенный от корня /var?

> Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...

Нерелевантно. ну не создают / и /usr нагрузку в наши времена (/srv и /var, да), равно как и не повышают надежность. Ограничения на размер тоже безразличны, когда ты видел в последний раз root _tape_?

Ответить | Правка | Наверх | Cообщить модератору

277. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorinemail (ok), 03-Ноя-11, 04:20 
>> А теперь обратите внимание на вид, открывающийся справа: это размер /usr+/
>> по сравнению с размером /
> Строго похрен.

Не скажи.

> Много ты видел систем где /usr находится на отдельном физическом носителе по
> сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.

В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.

Ещё порой ставил /usr вперёд: тогда не так страшен промах вида hda вместо hda1 (и однажды  именно эта предосторожность и спасла, когда надумал извернуться и засунуть честный PC-DOS 7 на расширенный раздел, а он снёс первый попавшийся).  Сейчас обычно вперёд своп по той же главной причине.

>> Чуть дальше можно будет оценить воронку от прямого попадания бэда в /var.
> А что это имеет общего с объединением / и /usr?

См. вид, открывающийся справа.

Заметь, /+/usr по гигу на всё про всё у меня бывают, там в /usr практически ничего ценного нет и отделять его смысла соответственно тоже: диаметр мишени особо не уменьшится.

--- сервер ---
791M    /    # CF: совмещённый
114M    /usr

474M    /    # SAS: совмещённый
115M    /usr

--- десктоп ---
7.6G    /
5.4G    /usr    # ноут: совмещённый с /

568M    /
6.6G    /usr    # десктоп: отдельный

У ноута /usr тоже совмещённый, поскольку точно есть батарейка (без электрика и уборщицы по дороге до материнки) и эксперименты с oops'ами провожу нечасто.

На десктопе contra для меня тут одно, но есть: дежурный бэкап системы чуточку (а восстановление -- чуть больше) усложняется.

> Или (испуганно) кто-то имеет отдельный /usr, но неотделенный от корня /var?

Не, ну горячие данные первей отцеплять надо, кто ж спорит.

>> Это если даже Multi-Disk HOWTO не почитать и вообще интересоваться только десктопами...
> Нерелевантно.

Категорично.

> ну не создают / и /usr нагрузку в наши времена (/srv и /var, да),
> равно как и не повышают надежность.

Саш, ну ты-то должен понимать, что "мало" не значит "вовсе нет".

Нагрузка на /usr на терминальном сервере с тонкими клиентами или на файловом с толстыми бывает приличной и в наши дни.  MTBF HDD довольно велик и шанс нарваться именно на вылезший до конца бэд (а не похоронный стук головой) субъективно тоже понизился -- но не до нуля.  Что с SSD, пока дружно выясняем на собственном лбу.

BTW у тебя сейчас шляпы под рукой нет?  Они /boot до сих пор предлагают дефолтно отдельный, а /home на корне?

> Ограничения на размер тоже безразличны, когда ты видел в последний раз root _tape_?

Этих в работе не застал, только уже отключенные шкафы (ну или терминалы, но там в машзал не совались, да и тортовницы там уже были, наверное).

PS: а ещё большой корень провоцирует загаживать его всяким хламом.  Правда, сделанный без двойного запаса может оказаться проще угробить, чем dist-upgrade'нуть, но это ж тоже понимать надо...

Ответить | Правка | Наверх | Cообщить модератору

291. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Zulu (?), 03-Ноя-11, 20:18 
> > Много ты видел систем где /usr находится на отдельном физическом носителе по
> > сравнению с /? Я ни одной. Отдельные разделы не считаются, естественно.
> В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.

Ух ты. А зачем?
Серьезно, я что-то подобное делал только в большой нужде, когда не мог отзекралить и /usr тоже.

> ...
> Сейчас обычно вперёд своп по той же главной причине.

Ну это прямо скажем не аргумент на отделение /usr, так как с этой же проблемой справляется -- как ты сам написал -- своп впереди или пустой раздел-заглушка, вообще не используемый

> Нагрузка на /usr на терминальном сервере с тонкими клиентами или на файловом с толстыми бывает приличной и в наши дни.  MTBF HDD довольно велик и шанс нарваться именно на вылезший до конца бэд (а не похоронный стук головой) субъективно тоже понизился -- но не до нуля.  Что с SSD, пока дружно выясняем на собственном лбу.

Ну файло файлсервера я бы тоже в /srv унес, а вот терминальные -- да, не подумал. С другой стороны, если /usr надо благодаря нагрузке уносить на более другой носитель, чего бы и / туда не унести? Много есть не просит. Быстрый и емкий, но небутабельный носитель? Видел такое один раз, какой-то сановский блейд с маленькой флешкой на пожарный случай и (проигнорированной) рекомендацией докупать еще сторадж-блейд. Но там бежал Солярис, которого было проще с iSCSI грузить чем отделить /usr.
Не, как ни крути мне все эти случаи кажутся маргинальными и решимыми с объединенным /+/usr.

А насчет бэдов -- я это решал регулярным смарт-селфтестом и raid1 на все системные вещи. Действую по правилу "Данные -- бэкапить, конфиги -- бэкапить, систему -- зеркалить"

> BTW у тебя сейчас шляпы под рукой нет?  Они /boot до сих пор предлагают дефолтно отдельный, а /home на корне?

шляпы нет.

Ответить | Правка | Наверх | Cообщить модератору

302. "В Fedora рассматривается предложение по переносу всех исполн..."  +/
Сообщение от Michael Shigorinemail (ok), 06-Ноя-11, 22:14 
>> В трёх метрах вон примерно такая стоит -- если RAID1 с / согласишься считать
>> более отдельным физически, чем один из дисков в нём, на котором в т.ч. /usr.
> Ух ты. А зачем? Серьезно, я что-то подобное делал только в большой нужде,
> когда не мог отзекралить и /usr тоже.

Точно не скажу, но как-то несколько лет назад ту машинку неосторожно развалил по части загрузки, наивно предполагая, что уж у меня-то дома всегда найдётся с чего загрузиться.  Эти два диска не особо большие, но достаточно шустрые, чтоб хотелось отрезать лишнее место от зеркального /home.

Заметь, я не спорю с пеной у рта, а говорю, что:
1) такие полтора процента случаев бывают;
2) вопрос элементарно решается в принципе (и давно решён в альте vsu@).

(решён путём запуска udev с обкоцаным набором правил из initramfs ради доступа к корню, сам этот udev ко времени монтирования корня глушится, а с корня стартует уже полновесный -- при этом опять же в альте нет /usr/lib*/udev за отсутствием физического смысла, но отнести запуск основного udev на после монтирования локальных ФС тоже можно попробовать)

> Ну это прямо скажем не аргумент на отделение /usr, так как с
> этой же проблемой справляется -- как ты сам написал -- своп
> впереди или пустой раздел-заглушка, вообще не используемый

Я тебе написал случай из жизни, только и всего.  Для меня это аргумент, а ты можешь пожать плечами и сказать -- "ну теперь-то ты знаешь, что надо было просто своп вперёд" (хотя это тоже было известно заранее, только тогда первые цилиндры были быстрей). :)

>> Нагрузка на /usr на терминальном сервере с тонкими клиентами
> Ну файло файлсервера я бы тоже в /srv унес, а вот терминальные
> -- да, не подумал.

Воот.  Есть многое на свете, друг Горацио, о чём Леннарт тоже не догадывается. :)

> С другой стороны, если /usr надо благодаря нагрузке уносить на более другой носитель,
> чего бы и / туда не унести?

Разумеется, я об этом подумал, когда писал.

> Не, как ни крути мне все эти случаи кажутся маргинальными

Вот этого слова я и ждал, спасибо.  Так вот мне не по нраву списывание в маргиналов без как минимум веских технических обоснований (т.е. это "майнстрим" должен обосновывать, а не "маргиналы", если он берёт на себя такую инициативу и хочет быть достоин уважения).

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру