ISP backup и /tmp

Уж панель-то не забудет включить ротацию для логов и всем чем она управляет. Это же программа,а не админ, которому танчики забанили и он ищет где бы заморочиться.

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

Ну раз не умеют, может и не надо вообще пытаться прогнозировать?

можно и с LVM разбить одним разделом, если уж так хочется LVM. Убунту поставьте - там мастер установки научит как.

Я думаю, разработчики получше вас знают свою целевую аудиторию и их потребности. Если они сделали существующую схему, значит были предпосылки.

Никто не идеален, и предусмотреть что какой-то робот наплодит 100500 писем, чем засрет /var/spool/mqueue а вместе с ним и все остальное... Так лучше я лишу его такой возможности.

можно, да. но от бинарников спасет. лучше закрыть часть возможностей, нежели не закрывать.

maildir'ы общей емкостью 200гб себя очень плохо чувствовали на ext3, и гораздо лучше на xfs.

возможно я не умею правильно готовить ext3. noatime/nodiratime сильно не помогали.

WoT - это святое )

А смысл тогда в LVM?

Вот потому, что она "не админ" - вполне может включить ротацию раз в сутки. А логи клиентов за это время - засрут все. Никогда не видели error.log для сайта за сутки на 5Gb? При _нормальной_ работе, с точки зрения пользователя. Еще примеры Вам alw привел.

Никакая программа не может такое спрогнозировать. Самая супер-дупер, чего уж там говорить про ispmanager.

Нет. Только в том, что кто-то своевременно не изменил размеры разделов. Системный администратор не компетентен / вовсе отсутствовал.

Кстати, если "полно места было на других разделах" - что-то таки должно было еще работать. Вместо того, чтобы из-за проблемы в /var/log/ - не работать _всему_. Интересно, подобный сценарий будет "понятен" клиенту? Что сайты у него не работают только потому, что логи некуда писать?

Прогнозировать можно и нужно. Ошибетесь в прогнозе - перепланируете разбивку, добавив места именно туда, где оно заканчивается.

И чтобы сделать бекап баз данных - Вы для всего тома LVM с _одним_ разделом будете снапшот делать?

Вы же не создаете каждому демону по разделу? Так вот и нет у вас никакой изоляции. Вместе с /var/spool/mqueue засрется весь /var и помрут другие программы. Скорее всего это будет mysql и syslog.

Это все мышиная возня. Играйте лучше в танчики.

ну вот же одепты пишут :

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

Ну syslog жалко, наверное... Зато с чего апачу помереть? Логи некуда писать будет - жаль, конечно. Но сайты работать будут, т.к. разделы под файлы пользователей, /tmp и раздел под данные mysql - не засраны.

Все идиоты, один я д'Артаньян... Ну, не нравится - не еште. Что так взъелись-то? Али имеете какое-то отношение к ISP и "хвалебный" отзыв о сем чуде енженерной мысли обидел?

Это уже не online, увы. Или не знали? Уменьшение многих FS потребует отмонтирования & fsck & ресайза offline - увы. Порядка нескольких часов все в дауне.

mysql - по дефолту, centos и debian, стоит в var если место закончится - сайты работать не будут базы упадут, да и ещё побьются, если в момент, будет активная запись.

Ну а я знаю какие каталоги следует выделить из /var на отдельные разделы, чтобы базы "не упали и не побились"? На том самом стандартном Debian и CentOS.

Вам рассказать - или сами догадаетесь?

А может и не следует, всё зависит от TЗ

сейчас модель универсальная

/

swap

tmp

--

И многих это устраивает.

Если можно вообще не следить за разделами, может сразу выбрать статистически наименее проблемную конфигурацию? Есть, конечно и минусы, но в целом довольно хороший выбор.

Как сайтовладелец я не понимаю зачем мне обязательно админу платить, все равно он в танчики режется. Вот у ТС тот сисадмин, который устанавливал даже не справился с разбивкой.

И другие были разделы перечислены.

На всяких там "проверенных временем" Centos, где нет /var/run в памяти, из-за переполнения /var могут не стартовать любые демоны, потому что им негде будет создать pid-файл.

В любом случае ничего хорошего от переполнения любого раздела не будет. Это нештатная ситуация и ее нужно исключить.

Может и буду. Это не так страшно.

Ради отсутствия необходимости платить сисадмину каждый месяц они с удовольствием потерпят.

Я решительно против увеличения энтропии вообще и разбивки дисков, создающей ненужные проблемы, в частности.