Стратегия управления файловыми системами (Для десктопа - не для сервера)
Модератор: Модераторы разделов
Стратегия управления файловыми системами
Во 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 процентов выигрыша на сборке очень больших пакетов, несчетный - на сборке _очень_ большого количества маленьких).
/
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 процентов выигрыша на сборке очень больших пакетов, несчетный - на сборке _очень_ большого количества маленьких).
Re: Стратегия управления файловыми системами
Для бинарно-пакетных дистрибутивов imho наверняка хватит одного сплошного /usr и /var
А, вот еще, под /boot выделяю минимально возможный раздел на ext2, который не монтируется по умолчанию.
А, вот еще, под /boot выделяю минимально возможный раздел на ext2, который не монтируется по умолчанию.
- VN_MAClover
- Сообщения: 1233
- Статус: Человек с бульвара Капуцинов
Re: Стратегия управления файловыми системами
Снимаю шляпу :thumbsup: !
У меня правда /home просто на отдельном винте из-за страха потерять данные, что год назад произошло из-за смерти винта (хотя для ноута это уже невозможно), /tmp -> /var/tmp, а /usr я не делил.
Интересно, а как вывести оптимальный размер разделов для распространённых сегодня объёмов винта, типа 160 или 250 гиг?
И раздел /boot я тоже выделил себе.
Наконец, tmpfs я ещё не пробовал, но читал как-то, что при нынешних объёмах оперативки можно и от swap отказаться, то есть классический совет swap = RAM x 2 уже можно забыть. Кто что про это думает?
У меня правда /home просто на отдельном винте из-за страха потерять данные, что год назад произошло из-за смерти винта (хотя для ноута это уже невозможно), /tmp -> /var/tmp, а /usr я не делил.
Интересно, а как вывести оптимальный размер разделов для распространённых сегодня объёмов винта, типа 160 или 250 гиг?
И раздел /boot я тоже выделил себе.
Наконец, tmpfs я ещё не пробовал, но читал как-то, что при нынешних объёмах оперативки можно и от swap отказаться, то есть классический совет swap = RAM x 2 уже можно забыть. Кто что про это думает?
In RMS we trust.
Зачем нам Ваши окна, если LAMPочка даёт достаточно света?
Зачем нам Ваши окна, если LAMPочка даёт достаточно света?
Re: Стратегия управления файловыми системами
(VN_MAClover @ Понедельник, 29 Ноября 2004, 20:28) писал(а):Интересно, а как вывести оптимальный размер разделов для распространённых сегодня объёмов винта, типа 160 или 250 гиг?
IMHO размер "служебных" (/var, /usr) размеров зависит от того сколько ты туда софта собираешься ставить и что ты с этим софтом собираешься делать. Остатки можно просто отдать под /home или еще как разбить, например отдельный (большой) раздел для общеюзерской файлопомойки (ну и еще по сети его же расшарить и т.п.)
Re: Стратегия управления файловыми системами
Наконец, tmpfs я ещё не пробовал, но читал как-то, что при нынешних объёмах оперативки можно и от swap отказаться, то есть классический совет swap = RAM x 2 уже можно забыть. Кто что про это думает?
А вот разработчики Mandrake почему-то никак не хотят про это забывать! На моём компе с 512М оперативки при установке не самой последней версии (10.0) их дистриба попробовал запросить те же 512 и под своп. И как же инсталятор сильно забеспокоился! Чего, мол, так мало? А уверены ли вы? И т.п.
Don't trouble troubles until troubles trouble you!
Re: Стратегия управления файловыми системами
2VN
В приницпе без свопа обойтись можно - начиная с 512 Мб точно (меньше не проверял:-)). Даже FreeBSD при установке через sysinstall нынче это позволяет - только предупреждает, что инсталляция оборвется, если памяти не хватит, по файловые системы монтирует (раньше категорически отказываласб).
Но своп я все равно выделяю 2RAM (винты то нвнче большие, что жмотничать?). Именно для предотвращения переполнения tmpsf/mfs на сборке больших пакетов.
И еще касаемо больших винтов - все, кроме /home и /usr/local, поддается точному расчету (в Линуксе еще /opt трудно рассчитать - никогда не знаешь, куда тот же KDE или Qt из пакетов захотят устанавливаться). Так что: все считанное, /usr/local - сколько не жалко с запасом, /home - все остальное (лишним не будет).
А boot я выделять перестал (раньше под grub делал), потому что последнее время мне требовалось все 4 первичных раздела для экскрементов.
2Bolverk
И для них (ИМХО) отдельный /opt лишним не будет. А в остальном верно - под порты и проч. разделы не нужны по определению. Я ведь говорю - суть моей схемы в том, что легко восстановимо из дистрибутива, от того, что восстановимо с трудом (исходники и проч.) и восстановимо с _очень_ большим трудом (собственные данные)
Да, еще одно преимущество дробной разметки - можно точно рассчитать оптимальный размер блока под, например, /usr/src и /usr/ports отдельно от /usr/ports/distfiles - очевидно, что для двух первых умолчальные (во Free) 16 k слишком жирно.
Теперь о монтировании: я все монтиирую с noatime,nodiratime - в рейзере это дает заметный прирост быстродействия (см. соотв. измерения: http://unix.ginras.ru/apps/test008.html
С трудом представляю на десктопе ситуацию, когда потребуется atime. М.б. на сервере на предмет всякой безопасности?
В приницпе без свопа обойтись можно - начиная с 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. М.б. на сервере на предмет всякой безопасности?
Re: Стратегия управления файловыми системами
(alv @ Среда, 01 Декабря 2004, 10:08) писал(а):И для них (ИМХО) отдельный /opt лишним не будет.
/opt... Он у меня пустой и всегда был пустой, что там бывает-то? Насколько я знаю, туда любят ставиться всякие большие цельные, часто коммерческие пакеты. Ы?
Re: Стратегия управления файловыми системами
(Bolverk @ Среда, 01 Декабря 2004, 12:00) писал(а):(alv @ Среда, 01 Декабря 2004, 10:08) писал(а):И для них (ИМХО) отдельный /opt лишним не будет.
/opt... Он у меня пустой и всегда был пустой, что там бывает-то? Насколько я знаю, туда любят ставиться всякие большие цельные, часто коммерческие пакеты. Ы?
По стандарту HFS туда должны писаться такие вещи, как Qt, KDE, Gnome, OOo. И в некоторых дистрибутивах так и делается - в Archlinux, например.
Re: Стратегия управления файловыми системами
А собственно нужен ли /opt вообще? Что там такого, чего нельзя разместить в /usr/local например, и следует ли приумножать сущьности без необходимости?
Don't trouble troubles until troubles trouble you!
Re: Стратегия управления файловыми системами
(Jinn @ Вторник, 07 Декабря 2004, 5:45) писал(а):А собственно нужен ли /opt вообще? Что там такого, чего нельзя разместить в /usr/local например, и следует ли приумножать сущьности без необходимости?
Во FreeBSD например так и делается. Но в Линуксе придумали стандарт HFS, и все перечисленное предлагается ставить именно туда. Многие дистрибутивы так и начали делать. И, помнится, cdrtools из исходников по умолчанию конфигурится с префиксом /opt. ИМХО - неудобно, т.к. нужно делать каталог /opt/bin, в нем - симлинки на /opt/prog_name/bin, вносить в $PATH и так далее. Но - претензии на стандарт:-)
Re: Стратегия управления файловыми системами
Не, мне такой стандарт не ндравицца. И команда ALT Linux со мной, похоже, согласна
- VN_MAClover
- Сообщения: 1233
- Статус: Человек с бульвара Капуцинов
Re: Стратегия управления файловыми системами
(Jinn @ Вторник, 07 Декабря 2004, 5:45) писал(а):А собственно нужен ли /opt вообще? Что там такого, чего нельзя разместить в /usr/local например, и следует ли приумножать сущьности без необходимости?
Если мне не изменяет память, в глубокой древности (году так в 1996 :P ) /opt был изобретён, а, точнее, заимствован из одного из коммерческих UNIX, чтобы размещать именно в нём коммерческие программы, которые начали появляться для Linux. Во всяком случае, Applixware Office for Linux и Empress ставились туда и только туда.
Это потом выяснилось, что многие программы, даже коммерческие, ставятся в /usr/local и от этого хуже не работают, а самих коммерческих программ - пара десятков, из тех, что прижились. И тут пошёл изврат на тему, что же делать с этим /opt.
Кстати, KDE поначалу норовил установиться именно в /opt из-за общеизвестных проблем с лицензией.
Я всегда считаю, что стандарты надо соблюдать, а то получится одна большая форточка, но иной раз про неудачные стандарты лучше просто тихо забыть.
In RMS we trust.
Зачем нам Ваши окна, если LAMPочка даёт достаточно света?
Зачем нам Ваши окна, если LAMPочка даёт достаточно света?
Re: Стратегия управления файловыми системами
(VN_MAClover @ Среда, 08 Декабря 2004, 2:46) писал(а):Я всегда считаю, что стандарты надо соблюдать, а то получится одна большая форточка, но иной раз про неудачные стандарты лучше просто тихо забыть.
С другой стороны - лучше один плохой стандарт, чем два хороших и тем более четыре замечательных:-)
Хотя, применительно к конкретному случаю с /opt - согласен, хорошо бы его в /dev/null
- VN_MAClover
- Сообщения: 1233
- Статус: Человек с бульвара Капуцинов
Re: Стратегия управления файловыми системами
(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.
In RMS we trust.
Зачем нам Ваши окна, если LAMPочка даёт достаточно света?
Зачем нам Ваши окна, если LAMPочка даёт достаточно света?
Re: Стратегия управления файловыми системами
А я считаю, что правильней всего иметь:
/boot - ext2, не монтируется по умолчанию;
/ - ext2, по умолчанию ro;
/tmp - ext2;
/usr - reiserfs;
/usr/portage/distfiles - xfs;
/home - reiserfs из файла на разделе с xfs;
/var - ext3 из файла на разделе с xfs.
Главное - не забыть про /usr/portage/distfiles...
:yes:
/boot - ext2, не монтируется по умолчанию;
/ - ext2, по умолчанию ro;
/tmp - ext2;
/usr - reiserfs;
/usr/portage/distfiles - xfs;
/home - reiserfs из файла на разделе с xfs;
/var - ext3 из файла на разделе с xfs.
Главное - не забыть про /usr/portage/distfiles...
:yes:
Re: Стратегия управления файловыми системами
а нахрена, если не секрет,
?из файла на разделе с xfs
слава роботам!
Re: Стратегия управления файловыми системами
t elide: а xfs, говорят, хорошо с большими файлами работает.... кстати, у меня один хард по xfs'ом - для фильмов - очень удобно, качественно и быстро работал.
подумал -> выпил -> подумал -> ... но недавно врачи запретили пить.
Re: Стратегия управления файловыми системами
elide
А чтобы не плодить разделы сверх меры. Корень во внешний файл не засадишь, /boot тоже, /tmp можно, но себе дешевле не, а остальное - пожалуйста... А почему именно XFS D.W.[q] объяснил:
(elide @ Пятница, 04 Февраля 2005, 18:10) писал(а):а нахрена, если не секрет,?из файла на разделе с xfs
А чтобы не плодить разделы сверх меры. Корень во внешний файл не засадишь, /boot тоже, /tmp можно, но себе дешевле не, а остальное - пожалуйста... А почему именно XFS D.W.[q] объяснил:
а xfs, говорят, хорошо с большими файлами работает.... кстати, у меня один хард по xfs'ом - для фильмов - очень удобно, качественно и быстро работал.(D.W. @ Пятница, 04 Февраля 2005, 21:24) писал(а):t[b] elide:
Re: Стратегия управления файловыми системами
" /usr/portage/distfiles - xfs "
всё таки дистфилес - это сборник небольших фалов ,а xfs оптимизированна для хранения больших файлов
как впрочем и /home
поэтому ваша раскладка фс несколько неудобна
wolf_black добавил в 05.02.2005 13:30
xfs удобен если много больших фалов - 500 мб и выше ,не рационально держать её для /home и дистфалов ,
ресурсы компа -ключ ко всему
всё таки дистфилес - это сборник небольших фалов ,а xfs оптимизированна для хранения больших файлов
как впрочем и /home
поэтому ваша раскладка фс несколько неудобна
wolf_black добавил в 05.02.2005 13:30
xfs удобен если много больших фалов - 500 мб и выше ,не рационально держать её для /home и дистфалов ,
ресурсы компа -ключ ко всему
Quae videmus quo dependet vultus. (лат) - То, что мы видим, зависит от того, куда мы смотрим.
Re: Стратегия управления файловыми системами
А у меня все просто.
/ - один раздел.
/data - другой раздел или винт.
В /data находятся все данные и мой хомяк.
При этом хомяк выступает только как хранилище настроек, никаких документов там нет.
Всё в /data/{Documents,Develop,Video,Music} и тому подобное.
То есть всё наоборот, не данные в хомяке, а хомяк в данных
Одна из причин такого расположения данных - так как я постоянно работаю с mc, сложновато найти то, что нужно среди огромного количества "скрытых" файлов и каталогов настроек.
Да, везде ext3.
/ - один раздел.
/data - другой раздел или винт.
В /data находятся все данные и мой хомяк.
При этом хомяк выступает только как хранилище настроек, никаких документов там нет.
Всё в /data/{Documents,Develop,Video,Music} и тому подобное.
То есть всё наоборот, не данные в хомяке, а хомяк в данных
Одна из причин такого расположения данных - так как я постоянно работаю с mc, сложновато найти то, что нужно среди огромного количества "скрытых" файлов и каталогов настроек.
Да, везде ext3.
ArchLinux / IceWM
Re: Стратегия управления файловыми системами
(madskull @ Суббота, 05 Февраля 2005, 10:43) писал(а):Одна из причин такого расположения данных - так как я постоянно работаю с mc, сложновато найти то, что нужно среди огромного количества "скрытых" файлов и каталогов настроек.
хм мне казалось всегда что с помощью mc это проще всего сделать ,не поделитесь почему ?
Quae videmus quo dependet vultus. (лат) - То, что мы видим, зависит от того, куда мы смотрим.
Re: Стратегия управления файловыми системами
(wolf_black @ Суббота, 05 Февраля 2005, 13:30) писал(а):xfs удобен если много больших фалов - 500 мб и выше ,не рационально держать её для /home и дистфалов ,
ресурсы компа -ключ ко всему
Кхм... Я читал, что преимущество XFS перед ReiserFS начианется с файлов больше 10-15 Мб...
P.S.: Я писал, что /home должен быть в разделе с ReiserFS, сведённым в loop на XFS...
Re: Стратегия управления файловыми системами
не путаете ? я читал что наоборот преимущество reiserfs проявляется для большого количесва файлов размером 10-15мб
и менее ,но начиная с около 500 м выше разница по скорости заметна очень ,имхо xfs проявлет лучше чем рейсер
и менее ,но начиная с около 500 м выше разница по скорости заметна очень ,имхо xfs проявлет лучше чем рейсер
Quae videmus quo dependet vultus. (лат) - То, что мы видим, зависит от того, куда мы смотрим.
Re: Стратегия управления файловыми системами
XFS vs ReisrFS - мои измерения: http://unix.ginras.ru/apps/test008.html
Похоже, что для XFS изошник - это еще не большой (или небольшой) файл:-)
Похоже, что для XFS изошник - это еще не большой (или небольшой) файл:-)
Re: Стратегия управления файловыми системами
во результат на лицо ! правда в аське сегодня сказали (тоже спроли на эту тему ) ,что с файлом 2гб ,xfs ведёт уже быстрее рейсера :new_blink: (что за файл на 2гб на ум не приходит ничего кроме DVD -образа)
Quae videmus quo dependet vultus. (лат) - То, что мы видим, зависит от того, куда мы смотрим.
Re: Стратегия управления файловыми системами
Для czarker:
вот меня и интересует, почему бы и не плодить разделы? они ведь для того и были придуманы? или нет?
ну это я понял, не тупой.А чтобы не плодить разделы сверх меры.
вот меня и интересует, почему бы и не плодить разделы? они ведь для того и были придуманы? или нет?
слава роботам!
Re: Стратегия управления файловыми системами
(wolf_black @ Суббота, 05 Февраля 2005, 16:58) писал(а):во результат на лицо ! правда в аське сегодня сказали (тоже спроли на эту тему ) ,что с файлом 2гб ,xfs ведёт уже быстрее рейсера :new_blink: (что за файл на 2гб на ум не приходит ничего кроме DVD -образа)
Вот и я к тому - типа под фильмы... как оно там называется, самое-то рассамое качество?
alv добавил в 05.02.2005 17:24
(elide @ Суббота, 05 Февраля 2005, 17:01) писал(а):Для czarker:
ну это я понял, не тупой.А чтобы не плодить разделы сверх меры.
вот меня и интересует, почему бы и не плодить разделы? они ведь для того и были придуманы? или нет?
ИМХО - именно для этого. Так что паркуа бы и не наплодить, если нужно?
Re: Стратегия управления файловыми системами
Кхм... ИМХО на домашнем компьютере иметь 6 разделов - более чем достаточно.
И вообще, лично мне жаль впустую потраченного места.
И вообще, лично мне жаль впустую потраченного места.
Re: Стратегия управления файловыми системами
(czarker @ Суббота, 05 Февраля 2005, 14:59) писал(а):P.S.: Я писал, что /home должен быть в разделе с ReiserFS, сведённым в loop на
XFS...
И все-таки, в чем преимущество раздела, расположенного в файле, перед таким же,
расположенным на физическом разделе? Я вот вообще никаких преимуществ не вижу и
считаю, что все эти loop - не от хорошей жизни. И не для.
Re: Стратегия управления файловыми системами
(Bolverk @ Суббота, 05 Февраля 2005, 17:34) писал(а):(czarker @ Суббота, 05 Февраля 2005, 14:59) писал(а):P.S.: Я писал, что /home должен быть в разделе с ReiserFS, сведённым в loop на
XFS...
И все-таки, в чем преимущество раздела, расположенного в файле, перед таким же,
расположенным на физическом разделе? Я вот вообще никаких преимуществ не вижу и
считаю, что все эти loop - не от хорошей жизни. И не для.
Согласен.
2czarker
При нынешних объемах винтов - жалеть-то особенно не очем. Если взамен предлагается комфорт.