unixforum.org

Во FreeBSD и ныне в DFBSD выработал для себя такую схему файловых систем:

/
swap
/tmp
/var
/usr
/usr/src
/usr/ports
/usr/ports/distfiles
/home

В DFBSD для этого хватает одного слайса (max=16), во FreeBSD приходилось разносить на два (1 - от / до /usr, 2 - от /usr/src до /home). Обоснование: все регулярно модифицируемое - пользовательские данные, обновляемое через cvs - изолируется от того, что устанавливается с дистрибутива. И при переустановке системы (я не говорю, что ее нужно переустанавливать, но чем лучше мы к этому подготовимся, тем меньше ее вероятность:-)) под рукой бубут заведомо более свежие исходники системы, дерева портов и исходники для их сборки (про собственные данные уже и не говорю).

Для доведения картины до логического конца - из /usr следовало бы выделить /usr/X11R6 и /usr/local - но вычислить объем под последний мне было лень.

Для Линукса схема схожая, но чуть иначе - из-за отсутствия слайсов о лишь одного extended раздела (в предположении единственной ОСи на диске):

/ - первичный, маленький
swap - первичный

extended с логическими разделами:
/tmp
/var
/usr
/usr/src
/opt
/usr/local
/usr/local/src
для систем типа CRUX/Arch
/var/abs - под евойные порты (или их аналог в CRUX)
/var/cache/src - для их исходников

/home - первичный

В любом случае идея в том, чтобы отделить наворованное непосильным трудом из сети (за счет трафика, оплаченного потом и кровью), от того, что может быть установлено с дистрибутивного диска. И, опять же, собственные данные - от того и другого.

Да, еще: если памяти больше 512МБ, и в обеих ОСях /tmp можно вынести в tmpfs (mfs соответственно). А при сборке подмонтировать mfs/tmpfs в /usr/obj - или где оно там в данном дистрибутиве все собирается. Пустячек, а приятно (3-5 процентов выигрыша на сборке очень больших пакетов, несчетный - на сборке _очень_ большого количества маленьких).

Для бинарно-пакетных дистрибутивов imho наверняка хватит одного сплошного /usr и /var
А, вот еще, под /boot выделяю минимально возможный раздел на ext2, который не монтируется по умолчанию.

Снимаю шляпу :thumbsup: !

У меня правда /home просто на отдельном винте из-за страха потерять данные, что год назад произошло из-за смерти винта (хотя для ноута это уже невозможно), /tmp -> /var/tmp, а /usr я не делил.

Интересно, а как вывести оптимальный размер разделов для распространённых сегодня объёмов винта, типа 160 или 250 гиг?

И раздел /boot я тоже выделил себе.

Наконец, tmpfs я ещё не пробовал, но читал как-то, что при нынешних объёмах оперативки можно и от swap отказаться, то есть классический совет swap = RAM x 2 уже можно забыть. Кто что про это думает?

(VN_MAClover @ Понедельник, 29 Ноября 2004, 20:28) писал(а):Интересно, а как вывести оптимальный размер разделов для распространённых сегодня объёмов винта, типа 160 или 250 гиг?

↑

IMHO размер "служебных" (/var, /usr) размеров зависит от того сколько ты туда софта собираешься ставить и что ты с этим софтом собираешься делать. Остатки можно просто отдать под /home или еще как разбить, например отдельный (большой) раздел для общеюзерской файлопомойки (ну и еще по сети его же расшарить и т.п.)

Наконец, tmpfs я ещё не пробовал, но читал как-то, что при нынешних объёмах оперативки можно и от swap отказаться, то есть классический совет swap = RAM x 2 уже можно забыть. Кто что про это думает?

А вот разработчики Mandrake почему-то никак не хотят про это забывать! На моём компе с 512М оперативки при установке не самой последней версии (10.0) их дистриба попробовал запросить те же 512 и под своп. И как же инсталятор сильно забеспокоился! Чего, мол, так мало? А уверены ли вы? И т.п.

2VN

В приницпе без свопа обойтись можно - начиная с 512 Мб точно (меньше не проверял:-)). Даже FreeBSD при установке через sysinstall нынче это позволяет - только предупреждает, что инсталляция оборвется, если памяти не хватит, по файловые системы монтирует (раньше категорически отказываласб).

Но своп я все равно выделяю 2RAM (винты то нвнче большие, что жмотничать?). Именно для предотвращения переполнения tmpsf/mfs на сборке больших пакетов.

И еще касаемо больших винтов - все, кроме /home и /usr/local, поддается точному расчету (в Линуксе еще /opt трудно рассчитать - никогда не знаешь, куда тот же KDE или Qt из пакетов захотят устанавливаться). Так что: все считанное, /usr/local - сколько не жалко с запасом, /home - все остальное (лишним не будет).

А boot я выделять перестал (раньше под grub делал), потому что последнее время мне требовалось все 4 первичных раздела для экскрементов.

2Bolverk

Для бинарно-пакетных дистрибутивов imho наверняка хватит одного сплошного /usr и /var

И для них (ИМХО) отдельный /opt лишним не будет. А в остальном верно - под порты и проч. разделы не нужны по определению. Я ведь говорю - суть моей схемы в том, что легко восстановимо из дистрибутива, от того, что восстановимо с трудом (исходники и проч.) и восстановимо с _очень_ большим трудом (собственные данные)

Да, еще одно преимущество дробной разметки - можно точно рассчитать оптимальный размер блока под, например, /usr/src и /usr/ports отдельно от /usr/ports/distfiles - очевидно, что для двух первых умолчальные (во Free) 16 k слишком жирно.

Теперь о монтировании: я все монтиирую с noatime,nodiratime - в рейзере это дает заметный прирост быстродействия (см. соотв. измерения: http://unix.ginras.ru/apps/test008.html

С трудом представляю на десктопе ситуацию, когда потребуется atime. М.б. на сервере на предмет всякой безопасности?

(alv @ Среда, 01 Декабря 2004, 10:08) писал(а):И для них (ИМХО) отдельный /opt лишним не будет.

↑

/opt... Он у меня пустой и всегда был пустой, что там бывает-то? Насколько я знаю, туда любят ставиться всякие большие цельные, часто коммерческие пакеты. Ы?

(Bolverk @ Среда, 01 Декабря 2004, 12:00) писал(а):

(alv @ Среда, 01 Декабря 2004, 10:08) писал(а):И для них (ИМХО) отдельный /opt лишним не будет.

↑

/opt... Он у меня пустой и всегда был пустой, что там бывает-то? Насколько я знаю, туда любят ставиться всякие большие цельные, часто коммерческие пакеты. Ы?

↑

По стандарту HFS туда должны писаться такие вещи, как Qt, KDE, Gnome, OOo. И в некоторых дистрибутивах так и делается - в Archlinux, например.

А собственно нужен ли /opt вообще? Что там такого, чего нельзя разместить в /usr/local например, и следует ли приумножать сущьности без необходимости?

(Jinn @ Вторник, 07 Декабря 2004, 5:45) писал(а):А собственно нужен ли /opt вообще? Что там такого, чего нельзя разместить в /usr/local например, и следует ли приумножать сущьности без необходимости?

↑

Во FreeBSD например так и делается. Но в Линуксе придумали стандарт HFS, и все перечисленное предлагается ставить именно туда. Многие дистрибутивы так и начали делать. И, помнится, cdrtools из исходников по умолчанию конфигурится с префиксом /opt. ИМХО - неудобно, т.к. нужно делать каталог /opt/bin, в нем - симлинки на /opt/prog_name/bin, вносить в $PATH и так далее. Но - претензии на стандарт:-)

Не, мне такой стандарт не ндравицца. И команда ALT Linux со мной, похоже, согласна

(Jinn @ Вторник, 07 Декабря 2004, 5:45) писал(а):А собственно нужен ли /opt вообще? Что там такого, чего нельзя разместить в /usr/local например, и следует ли приумножать сущьности без необходимости?

↑

Если мне не изменяет память, в глубокой древности (году так в 1996 :P ) /opt был изобретён, а, точнее, заимствован из одного из коммерческих UNIX, чтобы размещать именно в нём коммерческие программы, которые начали появляться для Linux. Во всяком случае, Applixware Office for Linux и Empress ставились туда и только туда.

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

Кстати, KDE поначалу норовил установиться именно в /opt из-за общеизвестных проблем с лицензией.

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

(VN_MAClover @ Среда, 08 Декабря 2004, 2:46) писал(а):Я всегда считаю, что стандарты надо соблюдать, а то получится одна большая форточка, но иной раз про неудачные стандарты лучше просто тихо забыть.

↑

С другой стороны - лучше один плохой стандарт, чем два хороших и тем более четыре замечательных:-)

Хотя, применительно к конкретному случаю с /opt - согласен, хорошо бы его в /dev/null

(alv @ Четверг, 09 Декабря 2004, 11:32) писал(а):С другой стороны - лучше один плохой стандарт, чем два хороших и тем более четыре замечательных:-)

↑

Если мы о вечной теме, то хорошим (из бывших) я считаю только стандарт 1251, так как он учитывает особенности всех славянских кириллических языков + молдавского, за исключением одной буквы. Недаром именно этот стандарт прижился в Болгарии и бывшей Югославии, да и на Украине он популярен.
В общем, все на UTF-8, и у нас будет один нормальный стандарт, а не два хороших (Windows-1251 и ISO 8859-5) или даже девять (GOST, ISO, Win, KOI7, KOI8-R, KOI8-U, KOI8-RU, Alt, Mac) замечательных. :thumbsup:

(alv @ Четверг, 09 Декабря 2004, 11:32) писал(а):Хотя, применительно к конкретному случаю с /opt - согласен, хорошо бы его в /dev/null

↑

Я запихнул почти туда ссылкой на /usr/local/opt.

А я считаю, что правильней всего иметь:

/boot - ext2, не монтируется по умолчанию;
/ - ext2, по умолчанию ro;
/tmp - ext2;
/usr - reiserfs;
/usr/portage/distfiles - xfs;
/home - reiserfs из файла на разделе с xfs;
/var - ext3 из файла на разделе с xfs.

Главное - не забыть про /usr/portage/distfiles...
:yes:

а нахрена, если не секрет,

из файла на разделе с xfs

?

t elide: а xfs, говорят, хорошо с большими файлами работает.... кстати, у меня один хард по xfs'ом - для фильмов - очень удобно, качественно и быстро работал.

elide

(elide @ Пятница, 04 Февраля 2005, 18:10) писал(а):а нахрена, если не секрет,

из файла на разделе с xfs

?

↑

А чтобы не плодить разделы сверх меры. Корень во внешний файл не засадишь, /boot тоже, /tmp можно, но себе дешевле не, а остальное - пожалуйста... А почему именно XFS D.W.[q] объяснил:

(D.W. @ Пятница, 04 Февраля 2005, 21:24) писал(а):t[b] elide:

а xfs, говорят, хорошо с большими файлами работает.... кстати, у меня один хард по xfs'ом - для фильмов - очень удобно, качественно и быстро работал.

" /usr/portage/distfiles - xfs "
всё таки дистфилес - это сборник небольших фалов ,а xfs оптимизированна для хранения больших файлов
как впрочем и /home
поэтому ваша раскладка фс несколько неудобна
wolf_black добавил в 05.02.2005 13:30
xfs удобен если много больших фалов - 500 мб и выше ,не рационально держать её для /home и дистфалов ,
ресурсы компа -ключ ко всему

А у меня все просто.
/ - один раздел.
/data - другой раздел или винт.

В /data находятся все данные и мой хомяк.
При этом хомяк выступает только как хранилище настроек, никаких документов там нет.
Всё в /data/{Documents,Develop,Video,Music} и тому подобное.
То есть всё наоборот, не данные в хомяке, а хомяк в данных

Одна из причин такого расположения данных - так как я постоянно работаю с mc, сложновато найти то, что нужно среди огромного количества "скрытых" файлов и каталогов настроек.

Да, везде ext3.

(madskull @ Суббота, 05 Февраля 2005, 10:43) писал(а):Одна из причин такого расположения данных - так как я постоянно работаю с mc, сложновато найти то, что нужно среди огромного количества "скрытых" файлов и каталогов настроек.

↑

хм мне казалось всегда что с помощью mc это проще всего сделать ,не поделитесь почему ?

(wolf_black @ Суббота, 05 Февраля 2005, 13:30) писал(а):xfs удобен если много больших фалов - 500 мб и выше ,не рационально держать её для /home и дистфалов ,
ресурсы компа -ключ ко всему

↑

Кхм... Я читал, что преимущество XFS перед ReiserFS начианется с файлов больше 10-15 Мб...
P.S.: Я писал, что /home должен быть в разделе с ReiserFS, сведённым в loop на XFS...

не путаете ? я читал что наоборот преимущество reiserfs проявляется для большого количесва файлов размером 10-15мб
и менее ,но начиная с около 500 м выше разница по скорости заметна очень ,имхо xfs проявлет лучше чем рейсер

XFS vs ReisrFS - мои измерения: http://unix.ginras.ru/apps/test008.html

Похоже, что для XFS изошник - это еще не большой (или небольшой) файл:-)

во результат на лицо ! правда в аське сегодня сказали (тоже спроли на эту тему ) ,что с файлом 2гб ,xfs ведёт уже быстрее рейсера :new_blink: (что за файл на 2гб на ум не приходит ничего кроме DVD -образа)

Для czarker:

А чтобы не плодить разделы сверх меры.

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

(wolf_black @ Суббота, 05 Февраля 2005, 16:58) писал(а):во результат на лицо ! правда в аське сегодня сказали (тоже спроли на эту тему ) ,что с файлом 2гб ,xfs ведёт уже быстрее рейсера  :new_blink:  (что за файл на 2гб на ум не приходит ничего кроме DVD -образа)

↑

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

alv добавил в 05.02.2005 17:24

(elide @ Суббота, 05 Февраля 2005, 17:01) писал(а):Для czarker:

А чтобы не плодить разделы сверх меры.

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

↑

ИМХО - именно для этого. Так что паркуа бы и не наплодить, если нужно?

Кхм... ИМХО на домашнем компьютере иметь 6 разделов - более чем достаточно.
И вообще, лично мне жаль впустую потраченного места.

(czarker @ Суббота, 05 Февраля 2005, 14:59) писал(а):P.S.: Я писал, что /home должен быть в разделе с ReiserFS, сведённым в loop на
XFS...

↑

И все-таки, в чем преимущество раздела, расположенного в файле, перед таким же,
расположенным на физическом разделе? Я вот вообще никаких преимуществ не вижу и
считаю, что все эти loop - не от хорошей жизни. И не для.

(Bolverk @ Суббота, 05 Февраля 2005, 17:34) писал(а):

(czarker @ Суббота, 05 Февраля 2005, 14:59) писал(а):P.S.: Я писал, что /home должен быть в разделе с ReiserFS, сведённым в loop на
XFS...

↑

И все-таки, в чем преимущество раздела, расположенного в файле, перед таким же,
расположенным на физическом разделе? Я вот вообще никаких преимуществ не вижу и
считаю, что все эти loop - не от хорошей жизни. И не для.

↑

Согласен.
2czarker

При нынешних объемах винтов - жалеть-то особенно не очем. Если взамен предлагается комфорт.