>>>>>>А если такой вариант: про*бал я место при разметке (в /var получилось
>>>>>>мало, в /usr много). Можно ли как-нить по-живому перерезать это пространство?
>>>>>>
>>>>>
>>>>>с обычной UFS нельзя, если vinum - можно, но не резать, а
>>>>>раздвигать
>>>>>так сказать
>>>>
>>>>GROWFS(8)
>>>
>>>
>>>Citate from (man growfs):
>>>
>>>Currently growfs can
>>> only enlarge unmounted file systems. Do
>>>not try enlarging a mounted file
>>> system, your system may panic and you
>>>will not be able to use the file
>>> system any longer. ......... In
>>>fact, you can only increase the size of the file system.
>>> Use
>>> tunefs(8) for other changes.
>>
>>Я читаю маны ;-p
>>
>>Ты полагаешь, это сущ. деталь в данном аспекте?
>>О нет, главное, что действильно происходит рост FS.
>
>Мораль как бы такова, что существующую ufs нельзя перезать... :(
да ладно вам, мораль проста, если за текущим слайсом есть свободные
цилиндры, а я не встречал таких запасливых, то growfs в жилу, ну или
если vinum, если же я вклячил второй диск или хочу изменить нарезку -
разбивку, то увы - за счет ЧЕГО?
А посему вывод - правильно разбивать с САМОГО начала и с возможностью
будущих mount-point'ов новых дисков, например:
/ - не больше 100MB
/tmp - как отдельная FS и не меньше 200-300MB, а при огромном кол-ве пользователей и задач >500MB или 1GB (удобнее не придумаешь, вот сделали бы как в Solaris tmp-fs вообще была бы красота)
/usr - не менее 2GB
[/usr/local - либо не делать отдельно, либо отдельно на отдельном диске -
последний случай удобен для хостинга и вообще если есть диск и много www]
/var - не менее 500MB, лучше не менее 1GB
/pub - фиолетово, удобно использовать для последующих mount-point'ов
других дисков
/scratch - для пользовательского говна и их совместной работы, первоначально фиолетов размер, тоже для последующих mount-point'ов внутри,
как и с /pub
/home - все оставшееся и зависимо от количества пользователей
теперь попробуем рассмотреть: /pub и /scratch в ПРИНЦИПЕ можно опустить
или взять одну из них, зависит от целей и задач.
/var можно не целиковой, а дополнительно
/var/log
/var/mail
Теперь соль: угадать тот слайс, который нужно будет расширять - его
делать последним, а его конкурента - предпоследним, все это выясняется
из предназначения сервера.
Допустим:
/pub - несущественно, внутри можно номинально сделать корень ftp, чтобы
он был не в /var и не в "/" корне
/var/log
/var/mail
/home
к примеру у нас четыре претендента, если сервер для интерактивного счета,
то выбор падает на /home, если на нем живет почта, то претендент /var/mail, иначе /var/log В итоге получаем последние слайсы:
/var/log - если почта запрещена
/home
почему home последний - потому что один хрен не хватит места и будет
рано или поздно перенесен на другой или несколько дисков, тогда после
переноса останется место которое можно будет расширить под /var/log
и/или /var/mail или если цельный /var то целиком под него
Другой вариант, сделать с точность наоборот, предпоследним /home,
а последним /var, практически те же сны
Прим: я рассказал свою технологию, а /home всего лишь как пример характерный для многопользовательского интерактивного сервера (хотя на
самом деле на таких серверах home вообще по другому делается :). эта
технология жесткая лишь в отношении:
/
/tmp - обязательно отдельной FS-tmp, даже если эта FS сдохла, останется
небольшой кусочек места на "/" - root-fs (там этот mount-point)
/usr и возможно /usr/local
/var[/var/mail|/var/log]
- тут больше ничего особенного придумать нельзя
В отношении остальных FS, размер, разбивка, местоположение прикидываются и планируются от задач и целей, ну и соответственно их объединение vinum, lvm, ccd все что будет удобно или нужно в соответствии с условиями, задачами, расширением и финансированием