Разметка диска под mail сервер (Рекомендации по размерам партиций)

[paralit]

Доброго времени суток всем. Ставлю Debian на серверную машинку, будет выполнять роль шлюза интернет и mail сервера, а в будущем может и веб сервера. Решил разбить диск, объемом 250 Гб, следующим образом:
/boot - 50Мб (тип: первичный)
swap - 4096 Мб (тип: логический) ramX2
/tmp - ?Mб, каталог временных файлов (тип: логический)
/ - 20 Гб (первичный)
/usr - 25 Гб для по (типа: ?)
/var - 50 Гб (протоколирование debag mode) (тип: логический)
Подскажите может я чего упустил, или может порекомендуете как более оптимальней разбить?

[rm_]

может порекомендуете как более оптимальней разбить?

/ - 250 Гб.

[murder]

Код: Выделить всё

/ - 1Gb
/boot - 100Mb
/home - 2Gb
/usr - 10Gb
/var - все остальное
swap - 2xram

Я бы так разбил

[paralit]

может порекомендуете как более оптимальней разбить?

/ - 250 Гб.

мда, конешно можно, но думаю не нужно

[rm_]

мда, конешно можно, но думаю не нужно

Смотрите сами, но я ведь не ради шутки написал, рекомендация основана на опыте установки и последующей поддержки не одной и не двух систем. Схема "одно логическое устройство хранения = один раздел" даёт гораздо больше гибкости и меньше проблем, а все аргументы против неё уже давно не актуальны.

[paralit]

мда, конешно можно, но думаю не нужно

Смотрите сами, но я ведь не ради шутки написал, рекомендация основана на опыте установки и последующей поддержки не одной и не двух систем. Схема "одно логическое устройство хранения = один раздел" даёт гораздо больше гибкости и меньше проблем, а все аргументы против неё уже давно не актуальны.

честно, не знаю плюсов и минусов ни за то ни за другое, в инэте пошарился так большинство почему то рекомендует разбивать...,
ничче не понимаю(с)

[red_dragon]

...
swap - 4096 Мб (тип: логический) ramX2
...

Просто к слову. Надеюсь Вы в курсе, что swap раздел не может быть больше 2048 Мб. Т.е. может, конечно, но ядро больше не видит. Если необходимо иметь большой файл подкачки, можно сделать больше соответствующих разделов по 2048 Мб. Однако, в наше время, при нынешних объёмах памяти, формула ram*2, уже не актуальна. А тем более, для почтовика с 2-мя гигами оперативной памяти, дисковый своп не нужен вообще, IMHO.

По теме:
/ - 20 Гб
Остальное в точку монтирования, куда будет складываться почта (/var /home, зависит от того какой Вы софт будете использовать и как его настраивать собираетесь).

[paralit]

...
swap - 4096 Мб (тип: логический) ramX2
...

Просто к слову. Надеюсь Вы в курсе, что swap раздел не может быть больше 2048 Мб. Т.е. может, конечно, но ядро больше не видит. Если необходимо иметь большой файл подкачки, можно сделать больше соответствующих разделов по 2048 Мб. Однако, в наше время, при нынешних объёмах памяти, формула ram*2, уже не актуальна. А тем более, для почтовика с 2-мя гигами оперативной памяти, дисковый своп не нужен вообще, IMHO.

По теме:
/ - 20 Гб
Остальное в точку монтирования, куда будет складываться почта (/var /home, зависит от того какой Вы софт будете использовать и как его настраивать собираетесь).

угу, после создания темы прочесывания инфы на сайте наткнулся на данное ограничение: http://www.debian.org/releases/etch/i386/apcs03.html.ru
спасибо, честно еще с почтовиком не определился, но хочу что бы в нем было побольше возможностей для настройки - наподобие mdaemon'a для винды.

[anjolio]

Смотрите сами, но я ведь не ради шутки написал, рекомендация основана на опыте установки и последующей поддержки не одной и не двух систем. Схема "одно логическое устройство хранения = один раздел" даёт гораздо больше гибкости и меньше проблем, а все аргументы против неё уже давно не актуальны.

Где-то на этом форуме читал, про некорректную настройку логирования, что приводило к забиванию раздела до отказа и вешало систему. И там же говорилось, что если вынести /var или /var/log на отдельный раздел, то система бы осталась жива, просто логи бы не писались.
З.Ы.: сам не пробовал, но ИМХО аргумент логичный.

[murder]

то система бы осталась жива, просто логи бы не писались.

Подтверждаю, не раз шкуру спасало

[Ленивая Бестолочь]

Однако, в наше время, при нынешних объёмах памяти, формула ram*2, уже не актуальна

формула ram*2 актуально всегда, т.к. при критическом сбое в своп сбрасываются (кор)дампы.
если оно конечно вас волнует вообще.

то система бы осталась жива, просто логи бы не писались.

у меня такое было - система на одном разделе. забилась не логами правда, а так:
во время долгих выходных бекапы (большие) должны были каждый день с нее копироваться по самбе.
учетка, под которой самба ходила на сервер заблокировалась из-за вирусни, которая подбирает пароли.
в скрипте копирования проверки не было и он пару недель все складывал локально в /mnt/samba.
итог: / - 100%
в систему никем не войти, mount/unmount/df не работает. даже есть все удалить все равно не работает.
пришлось перезагружать.

[paralit]

Еще интересный вопрос, параметры монтирования какие можно включать для разделов. Например для /var возможные параметры монтирования noatime, nodev и noexec. целесообразно ли? - у кого есть опыт работы когда данные опции были полезны? И есть ли разница в каком порядке я создаю разделы. кроме /boot я его первым определил, второй swap а дальше есть смысл в порядке определенном выстраивать tmp var и остальные разделы?

[little Jon]

Еще интересный вопрос, параметры монтирования какие можно включать для разделов. Например для /var возможные параметры монтирования noatime, nodev и noexec. целесообразно ли? - у кого есть опыт работы когда данные опции были полезны? И есть ли разница в каком порядке я создаю разделы. кроме /boot я его первым определил, второй swap а дальше есть смысл в порядке определенном выстраивать tmp var и остальные разделы?

noatime ставить целесообразно, нет смысла делать записи о последнем обращении к файлу, на почтовике такой необходимости обычно не бывает, меньше грузит диск. На tmp можно и виртуальный диск повесить, если его не хватит будет использваться swap. noexec это смотря как диск разбивать будешь, а то можно и исполнямые файлы отключить ненароком.

[red_dragon]

...
формула ram*2 актуально всегда, т.к. при критическом сбое в своп сбрасываются (кор)дампы.
если оно конечно вас волнует вообще.
...

Ну во первых под crash dump не требуется столько места. Максимум ram*1, а зачастую гораздо меньше. Во вторых, я не настолько "продвинут", что бы анализировать crash dump'ы. Мне гораздо проще и быстрей переустановить систему. Ну а в третьих, за всю мою практику (около десяти лет пользуюсь Linux в той или иной мере) все критические сбои системы происходили как раз, именно из за отказа накопителей...
А по сему, два раза не актуально, IMHO.

[Ленивая Бестолочь]

Ну во первых под crash dump не требуется столько места. Максимум ram*1, а зачастую гораздо меньше. Во вторых, я не настолько "продвинут", что бы анализировать crash dump'ы. Мне гораздо проще и быстрей переустановить систему. Ну а в третьих, за всю мою практику (около десяти лет пользуюсь Linux в той или иной мере) все критические сбои системы происходили как раз, именно из за отказа накопителей...
А по сему, два раза не актуально, IMHO.

ну я в этом тоже обсалютно не продвинут =)
просто по скромному опыту работы осталось мнение, что все "аварийные" технологии лучше делать правильно. если будет разбор полетов то могут и крешдамп попросить. по крайней мере я представляю себе такой случай, когда наша контора мы заказала анализ крешдампа, чтобы вытащить оттуда какую-нибудь информацию. в так случае я не хотел бы говорить, что его нет, по тому, что я забил на своп =)
насчет ram*1 или ram*2 для дампа - к сожалению уже не помню почему советуется именно *2. что-то связанное именно с дампами. тоже какая-то чисто гипотетическая ситуация, но см. выше. я об этом узнал на курсах по солярке - про линукс говорили то же самое.

[paralit]

Итак, итог моего разбитого диска:
/boot - 100 mb (первичный, занимает место 22 mb), файловая ext2
/ - 20 gb (логический), файловая ext3
/usr -25 gb (логический), файловая ext3
/var - 50 gb (логический), файловая Rfs, опции noatime,noexec,nodev
/swap - 4096 mb (логический), рама у меня 2048, система все равно больше этого не сможет использовать, но на всякий случай сделал х2 больше
/tmp - 512 mb (логический), по умолчанию если разбивать система отводит 400 с копейками метров, для ровного счета сделал 512, если прости так пусть будет, тем более размер позволяет, , файловая rfs
/home - все оставшееся место, 150 gb, файловая ext3
ну и в резерве еще один диск лежит не размеченный.
вот, возможно где то и больше поставил, но собственная практика юзанья покажет
Всем С П А С И Б О за внимание и участие.

[Goodvin]

А на каком разделе будете хранить собственно почту ?

[Ленивая Бестолочь]

/tmp - 512 mb (логический), по умолчанию если разбивать система отводит 400 с копейками метров, для ровного счета сделал 512, если прости так пусть будет, тем более размер позволяет, , файловая rfs

имхо в /tmp журналируемая ФС ни к чему.

[rm_]

/tmp - 512 mb (логический), по умолчанию если разбивать система отводит 400 с копейками метров, для ровного счета сделал 512, если прости так пусть будет, тем более размер позволяет, , файловая rfs

имхо в /tmp журналируемая ФС ни к чему.

А вообще, разве есть на сегодня причины не монтировать /tmp как tmpfs?
Неужели почтовые сервера кушают сильно много /tmp?

[paralit]

/tmp - 512 mb (логический), по умолчанию если разбивать система отводит 400 с копейками метров, для ровного счета сделал 512, если прости так пусть будет, тем более размер позволяет, , файловая rfs

имхо в /tmp журналируемая ФС ни к чему.

да но это фс лучше работает со множеством мелких файлов, или может я ошибаюсь.

А на каком разделе будете хранить собственно почту ?

/var

[Goodvin]

А на каком разделе будете хранить собственно почту ?

/var

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

Подумайте, что будет с почтовым сервером, если в случае неправильной настройки/поломки syslog у Вас заполнится /var на 100% ?
Что будет с самой системой, если в почту навалит чего-то нехорошего и у Вас заполнится /var на 100% ?

[paralit]

А на каком разделе будете хранить собственно почту ?

/var

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

Подумайте, что будет с почтовым сервером, если в случае неправильной настройки/поломки syslog у Вас заполнится /var на 100% ?
Что будет с самой системой, если в почту навалит чего-то нехорошего и у Вас заполнится /var на 100% ?

Исправил, вынес, /var/log и /var/mail в отдельные разделы. Осталось определиться тока какой почтовик поднимать.

[Goodvin]

Исправил, вынес, /var/log и /var/mail в отдельные разделы. Осталось определиться тока какой почтовик поднимать.

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

[paralit]

Исправил, вынес, /var/log и /var/mail в отдельные разделы. Осталось определиться тока какой почтовик поднимать.

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

Спасибо. И не собирался. А Поиском обзательно воспользуюсь.

[aSteklov]

имхо в /tmp журналируемая ФС ни к чему.

У меня тоже такое мнение было. Пока не рухнул /tmp под ext2 и на этапе загрузки не пришлось ремонтировать fs, банально переформатируя.
Причём несколько раз такое было. Потому что я... ну... выключаю питание удерживая кнопку 5 секунд :-)
А что, usr и opt у меня в ro-режиме смонтированы, есть bz2 архив корня и var и тех двух... Так что если что - быстро восстановлю ))))

[Ленивая Бестолочь]

У меня тоже такое мнение было. Пока не рухнул /tmp под ext2 и на этапе загрузки не пришлось ремонтировать fs, банально переформатируя.

чего-то я не очень понял, что у вас случилось.
ну рухнул /tmp - допустим.
если он не смонтируется на этапе загрузки - зачит все, что предполагалось писать в него будет писаться в каталог /tmp на корневой ФС.
вроде никакого рецидива :-\

[aSteklov]

чего-то я не очень понял, что у вас случилось.
ну рухнул /tmp - допустим.
если он не смонтируется на этапе загрузки - зачит все, что предполагалось писать в него будет писаться в каталог /tmp на корневой ФС.
вроде никакого рецидива :-\

вместо иксов - консоль с пояснением, что (перевод по памяти и неточный) ... не удалось смонтировать одну или несколько файловых систем (не root). И далее что-то типа ... проведите монтирование вручную
Рецидив - это повторение чего-то (как правило негативного). Рецидивы были. Пока я не пеформатировал в журналируемую.
А если хотите повторить - так например можете прописать в fstab винчестер, подключаемый по eSATA и отключить его перед следующим включением.
Linux version 2.6.25.20-0.1-default (geeko@buildhost) (gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) ) #1 SMP 2008-12-12 20:30:38 +0100