Bug 29126

Created attachment 5869 [details]
screenshot

При автоматической разбивке swap делается RAM*2

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

(In reply to comment #2)
> При автоматической разбивке swap делается RAM*2
> 
> 7Г / для сервера вполне подходяще. К сожалению, имеющаяся система описания
> разбиения дисков не позволяет делать сложные правила, нелинейно зависящие от
> имеющегося дискового пространства, а так как ставят "на посмотреть" часто в
> виртуалку, сильно задирать размер / тоже не очень хорошо.

Еще раз.
На сервере 8G ОЗУ.
Своп создался размером в 31G. Корень размером 7G. Посмотрите внимательно скриншот.

Вопрос: Почему?
Логично было бы наоборот, так как вы описываете: своп - 7G, корень 31G.

Может я не прав, что reopen. Вам конечно виднее. Но в таком виде автоматическая разбивка не имеет никакого смысла и в любом случае придется разбивать в ручную.
Единственное мне не понятно почему своп аж 31. Это в ~4 раза больше RAM.
Возможно тут бага. Возможно имело значение в том, что несколько раз был возврат на шаг Назад и какая-то переменная не очистилась и размер свопа в результате увеличился в 4 вместо 2. могу только догадываться.

(В ответ на комментарий №4)
> Может я не прав, что reopen. Вам конечно виднее. Но в таком виде автоматическая
> разбивка не имеет никакого смысла и в любом случае придется разбивать в ручную.
> Единственное мне не понятно почему своп аж 31. Это в ~4 раза больше RAM.
> Возможно тут бага. Возможно имело значение в том, что несколько раз был возврат
> на шаг Назад и какая-то переменная не очистилась и размер свопа в результате
> увеличился в 4 вместо 2. могу только догадываться.

Пересмотрел алгоритм. Для сервера там стоит RAM*4 но не более 32 Гб. К сожалению, все ситуации заранее предусмотреть сложно а, к сожалению,  самым неквалифицированным нашим пользователям, порою нужен самый большой tmpfs.

По поводу размера корня. Как я писал выше, сейчас в системе описания разбиения фактически может быть только один "резиновый раздел". Задать правило: "/ от 7 до 32 Гб, /var от 5 до бесконечности, но при этом /var в 5 раз более растяжим чем /" увы, нельзя. А минимум задают установки в виртуалки, которые тоже приходится учитывать, так как те, кто пишут обзоры (да и мы сами при тестировании) ставим системы именно в виртуалки.

При этом 7Г / на сервере (при том, что /home и /srv фактически находятся в /var), представляется мне вполне достаточным умолчанием.

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

(In reply to comment #5)
> (В ответ на комментарий №4)
> > Единственное мне не понятно почему своп аж 31. Это в ~4 раза больше RAM.
> > Возможно тут бага. Возможно имело значение в том, что несколько раз был возврат
> > на шаг Назад и какая-то переменная не очистилась и размер свопа в результате
> > увеличился в 4 вместо 2. могу только догадываться.
> 
> Пересмотрел алгоритм. Для сервера там стоит RAM*4 но не более 32 Гб.

Спасибо большое за ответ.
 
> В любом случае, разделы не перепутаны, хотя о их размерах и алгоритмах
> разбиения можно поспорить.

Нету смысла спорить. У каждого свои задачи. Меня смутили эти 31G и что своп больше корня оказался.

Вчера mike@ смотрел на мои "мучения" при ручной разбивке и высказывался что тоже имеет желание как-то упростить и ускорить этот процесс. В связи с чем у меня возникло предложение:
Не нужно усложнять интерфейс и алгоритмы при ручной разбивке. Достаточно добавить больше вариантов автоматической разметки. И более полно их описать. А то слова "Офисный сервер" не дают представление как будет произведена разметка.
Мест там вроде есть.

Я бы описал так и добавил такие варианты:
Офисный сервер (swap=RAM*4; /=7-32G; /var=5-остаток)
Сервер для HN (swap=RAM; /=20-40G; /var/lib/vz=5-остаток)
Сервер для чего-то еще (swap=RAM*2; /=7-32G; /usr=5-100G; /var=5-остаток)

и т.д. все это обсуждаемо.

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

Я подумал, что описывать словами предлагаемую разметку не очень просто. Например типична разметка с использованием рейда и поверх LVM. Будет не понятно и вопросы.
Предлагаю отображать это на картинке. Можно даже рисовать на лету с помощью graphviz.
Например вот такой простой скрипт позволяет получить такую картинку. Скрипт картинка во вложении.

Created attachment 5878 [details]
graphviz script

Created attachment 5879 [details]
result of script

(In reply to comment #6)
> Не нужно усложнять интерфейс и алгоритмы при ручной разбивке. Достаточно
> добавить больше вариантов автоматической разметки. И более полно их описать.
Предлагаю пощупать regular-server-20131015 с http://ftp.linux.kiev.ua/pub/Linux/ALT/people/mike/iso/mkimage-profiles/tmp/ и/или глянуть http://git.altlinux.org/people/mike/packages/?p=installer-distro-altlinux-server.git;a=blob;f=installer-distro-altlinux-server/initinstall.d/05-vm-profile;hb=HEAD

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

Думаю, эту багу обо всём и ни о чём с текущей формулировкой следует закрыть и сформулировать чётко технические:
- о пожелании возможности нескольких "резиновых" разделов
  (например, возможности сказать "остаток поделить между /var и /home поровну");
- о наличии в составе конкретных дистрибутивов более подходящих профилей.