[vadblm]

интелловский двухядерник 32бит, 4 Гб DDR3 »

Наверно всё же 64 бит, раз

4 Гб DDR3 »

Ну не Atom же там занюханый, а все остальные современные интеловские процы 64 бит могут.
Да и чтобы все 4 гига использовать, надо amd64 (не процессор, архитектуру).

Прошу совета, как правильно распределить дисковое пространство. »

250-ку разбить по умолчанию, две 750-ки объединить в gmirror, gstripe, или gconcat в зависимости от требований к сохранности, скорости и полезному объёму, и там держать /home.
Как-то так.

[YDen]

Здравствуйте.
Подниму свою тему, т.к железо закуплено, нужно ставить систему.

Постановка задачи такая же. Раид делать не буду по причине недостатка знаний.

Вопросы:
1. системе не "сильно много" 250Гб? Куда будет расходоваться этот объем?
2. какие файловые системы использовать.
3. свап нужен? Сколько?


Очень буду признателен за инструкции как правильно разметить диски.

Спасибо

[kim-aa]

Я бы делал так

hda = 250
hda1= \ = 240
hda2=swap= 10G

hdb=750
\home

hdc=750
\var

[YDen]

kim-aa,
Спасибо.
А файловую систему какую?

И чем \var отличается по функционалу от \home?

[xoomer]

И чем \var отличается по функционалу от \home? »

/var [wiki]

hda = 250 hda1= \ = 240 hda2=swap= 10G hdb=750 \home hdc=750 \var »

Прошу прощения, но, честно говоря, не знаю зачем под /var в школе нужно 750 Гб?.. )

Поддерживаю идею vadblm объединить два 750-Гб диска. Правда, как пользоваться

gmirror, gstripe, или gconcat »

понятия не имею. В любом случае, если нету времени Вам с этим разбираться, его можно примонтировать в какую-нибудь /home/big-files...

[kim-aa]

Прошу прощения, но, честно говоря, не знаю зачем под /var в школе нужно 750 Гб?.. ) »

Забавный вопрос.
А /home = 750 на сервере без пользователей значит никого не смущает?


1) Обычно, я люблю складировать в подкаталогах /var резервные копии.
2) почта любит /var
3) файлопомойки типа /public так же можно сносить в /var


YDen,

Я, честно говоря уже лет 5 с BSD не работал.

Какие файловые системы сейчас предлагаются при инсталляции?

[vadblm]

Раид делать не буду по причине недостатка знаний. »

С таким подходом можно вообще за дело не браться.

1. системе не "сильно много" 250Гб? »

Вообще-то много. Под систему при описанных задачах за глаза 20-30Гб.

Куда будет расходоваться этот объем? »

Ну и вопросики у вас. Кому знать, как не вам? Вообще говоря, мне сразу показался странным выбор носителей 250 + 2*750, но да ладно.

1) Обычно, я люблю складировать в подкаталогах /var резервные копии. 2) почта любит /var 3) файлопомойки типа /public так же можно сносить в /var »

1) и 3) можно с равным успехом держать в /home, это дело сугубо вкуса.
2) о почте ТС в задачах не заикался. Как и о БД, которые тоже любят /var (впрочем, эта любовь лечится).

Я, честно говоря уже лет 5 с BSD не работал. »

Тогда становится объяснимым ваш странный совет с одним большим корнем, очевидно вы забыли, что корень в FreeBSD по умолчанию без soft updates, что означает тормоза. Можно конечно их включить, но в любом случае это дурная затея - держать корень вместе со всем барахлом. Очень свободно можно получить кашу вместо ФС при сбое. Короче, если корень в порядке, то всё можно починить, если нет - то лезь за бэкапом, если он конечно есть... Отдельный маленький корень без SU на порядок надёжнее корня с SU и всем барахлом.

Какие файловые системы сейчас предлагаются при инсталляции? »

Та же что и раньше - UFS2. Есть возможность ставить систему и на ZFS, но это нетривиальная процедура, требующая плясок с бубном в Fixit, поскольку ТС даже простецкий GEOM пугает, то...

YDen, вы так и не сказали, какой полезный объём вам нужен и какая степень надёжности.

К примеру, при имеющемся оборудовании и для обеспечения максимальной надёжности, не используя ZFS (я бы всё же предпочёл ZFS), можно поступить так:
750 разбиваем почти по умолчанию:
/ - 1Гб
swap - 4Гб
/tmp - 1Гб
/var - 4Гб
/usr - 20Гб
/home - всё остальное.
Вторую 750-ку впоследствии включаем в зеркало с первой при помощи gmirror.
250:
swap (да, ещё один раздел для свапа): 4Гб
/var/backup (точка монтирования произвольна) - всё остальное, для дампов /, /var и /usr.
При желании, можно её также использовать для журналов /var, /usr, /home, по 4Гб разделы для каждого из журналов будет вполне достаточно.

[kim-aa]

Тогда становится объяснимым ваш странный совет с одним большим корнем, очевидно вы забыли, что корень в FreeBSD по умолчанию без soft updates, что означает тормоза. Можно конечно их включить, но в любом случае это дурная затея - держать корень вместе со всем барахлом. Очень свободно можно получить кашу вместо ФС при сбое. Короче, если корень в порядке, то всё можно починить, если нет - то лезь за бэкапом, если он конечно есть... Отдельный маленький корень без SU на порядок надёжнее корня с SU и всем барахлом. »

Да нет. У меня всю жизнь было по разделам.
Просто человек новенький.

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

К примеру, при имеющемся оборудовании и для обеспечения максимальной надёжности, не используя ZFS (я бы всё же предпочёл ZFS), можно поступить так: 750 разбиваем почти по умолчанию: »

Я лицо пристрастное (последние годы вожусь с Solaris , однако при желательности ZFS лучше пользовать OpenSolaris

[vadblm]

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

Не надо плохому учить. В линуксе или солярке с ZFS такое прокатит, но не в FreeBSD на UFS2, выше объяснил почему. А переразбивка новичку - да вы видать и плавать учите, бросая в омут.
Новичку при сомнениях следует пользоваться авторазбивкой, в 99% случаев она будет лучшей.

при желательности ZFS лучше пользовать OpenSolaris »

Мы же про фри говорим, а не про солярис. Так можно и до btrfs на линуксе договориться
Ну как сказать, в реализации ZFS на FreeBSD есть отдельные недочёты, главный из которых, пожалуй, незнакомство с ней (а так же с gpart) sysinstall'a. Всё обещают новый установщик, да видать будет только в 9-ке... А также необходимость крутить ядерные гайки при малом количестве памяти (4Гб и меньше), чтобы исключить возможность паники при исчерпании памяти ядра ARC'ом. Лично для меня эти минусы с лихвой перекрываются плюсами - неубиваемостью (copy on write же), гибкостью, отличной производительностью (prefetch) и превосходным софтверным RAID 5/6.