Подумай еще раз.

Разделы нужны на диске, на которой ставиться загрузчик

Плюсы партиций

• лишний шанс не допустить ошибку ( не принять диск за пустой )
• другая ОСь не примет диск за пустой и не разметит его автоматом
• kvm не обратит лишнего внимания на этот диск ( например, если на всём диске lvm pv или том mdadm, ось хост системы может автоматом обнаружить их и открыть ( для lvm pv - убирается фильрами lvm )

минусы партиций

• партицию не расширить, если не отмонтировать ФС на этой партиции. т.е. нужен будет даунтайм

Мне удобнее создавать ФС на всём томе, без партиций. Ты смотри сам

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

kvm не обратит лишнего внимания на этот диск ( например, если на всём диске lvm pv или том mdadm, ось хост системы может автоматом обнаружить их и открыть ( для lvm pv - убирается фильрами lvm )

вот этого не понял

слушай, а вот если использовать mbr+legacy и отдельный диск под /boot, то ведь тогда и на корне можно будет не создавать раздел?

В ВМ создай PV на всём томе, без партиций. Затем sync;sync;sync

Потом на хост системе выполни

pvscan
pvdisplay -C

Сюрприз. Убирается через фильтры ( /etc/lvm/lvm.conf, filter или global_filter )

Да. В случае с uefi тоже. Если не винда.

Можно еще файл ядра прокидывать с Хоста прямо до uefi, или если гость паравиртуализирован, тоже загрузить сразу в память и стартануть с него.

Таблица разделов помешать может разве что в случае ресайза диска с gpt.

Скорее всего да

ИМХО, мне паравиртуализация в xen как раз этим не нравилась - необходимость вытаскивать ядро и рамдиск из гостя, либо городить костыли с созданием гостевого рамдиска на хост-системе

подожди,я не понял, зачем в ВМ создавать сущности LVM?

По идее даже без boot можно, grub2 достаточно mbr+пару секторов для первичного и полуторного загрузчиков, а дальше ядро хоть на зашифрованном диске может лежать.

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

Для работы с дисками и разделами без перезагрузки. Хотя многие ограничения идут просто от того, что многие системы виртуализации блокируют изменение конфигурации работающих дисков, или игнорируют их.

Я как-то и на реальных машинах придерживаюсь идеологии «одно устройство - один раздел». Смысла в пилении дисков на разделы не вижу вообще - ведь может возникнуть ситуация, когда нет места на одном разделе, но есть дофига на другом, и надо заниматься всякими манипуляциями, чтобы это место переносить.

Да и если место кончится на этом разделе, его достаточно легко будет добавить. Правда придётся вм потушить. Вообщем тоже не вижу смысла внутри вм пилить на разделы.

Как хочешь. Разделы, кроме /home, особо и не зачем создавать

Плюсы партиций

Еще и /boot в случае чего спасает

партицию не расширить, если не отмонтировать ФС на этой партиции. т.е. нужен будет даунтайм

LVM вроде может такое?

не понимаю зачем создавать разделы даже на хост системе, не то что в виртуалках.
/boot or efi + / хватит всем.
вот когда смогу нормально линуксы с zfs грузить, тогда можно будет подумать.

boot, /, swap и /home по желанию, какой-нибудь /media/data, если диск большой.

Система отдельно, данные отдельно.

По крайней мере я так на поддиванном недосервере сделал. Остальные диски однораздельные.

Проблемы msdos и gpt партиций решаются только отказом от msdos и gpt партиций. Другие средства тут не катят

LVM без даунтайма работает с _собственными_ сущностями

/boot or efi + / хватит всем.

Для локалхоста хватит

и для хоста с другим именем хватит. или у тебя другое мнение на этот счёт?

Другое. И у меня, и у коллег

не хочешь поделиться?

Как уже сказал Radjah, система отдельно, данные отдельно

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

Во-вторых, облегчает перенос на новую ВМ. Переключил диск и вперёд

Если БД, то отдельно /oracle, отдельно /dbname-data*, /dbname-redo*, /dbname-uarc*

Если есть неопакеченый софт ( привет, кровавый интырпрайз ), то по возможности его лучше ставить на отдельный /opt

Ну и т.д.

Ну и по традиции, на домашней машине данные это /home. А /tmp лучше в tmpfs

Смотря что за вируалка, думаю что большинстве случаев не нужно...

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

Я делаю диск под систему в 10 гигов. А потом добавляю диски под конкретные задачи. Разделы не нужны. Разделы это про реальные диски, когда у тебя диски виртуальные, то смысла в этом нет.

Стоп, подожди, кто говорил «пилить»? Никаких распилов, один раздел на диск. Зачем? Да блин по привычке.

Подожди, я не понял. Я в рамках хост-ос создал LV и отдал его виртуалке. Зачем мне в виртуалке в этом диске создавать LV? Я разве не могу просто ФС создать и пользоваться?

А как ВМ отработает изменение размера выданного ей LV?

/boot or efi + / хватит всем.

А зачем /boot таки отдельный?

А зачем /boot таки отдельный?

ESP должен быть FAT32

Да и на железе не нужно,кроме бут/рут, как написали. Мы придерживаемся простой логики: на все локальные физические диски создаем партиции. Чтобы потом не обмануться fdisk или при загрузке сторонних лив сд. На все удаленные, fc, iscsi, или виртуальные диски для данных - не создаем. При просмотре монтировок сразу видно природу и назначение дисков.

Не согласен с вами

Фрагментация меньше может быть если правильно разбить(для каждой задачи по-разному)(конфиги не изменяются, а binы обновляются, например), соответственно скорость доступа повысится. Кто дефрагментацию часто делает - тому меньше раз ее делать(и быстрее), т.к «конфиги», например, не имеет смысл дефрагментировать.

ESP должен быть FAT32

Дык если без нее? Я вот на весь 3ТБ диск создал один раздел и гружусь не в режиме UEFI - чем мне это грозит?)

Ну и с UEFI вроде от прошивки зависит, вроде некоторые продвинутые умеют и в большее количество ФС.

Я вот на весь 3ТБ диск создал один раздел и гружусь не в режиме UEFI - чем мне это грозит?)

Когда-нибудь в будущем следующая материнская плата может оказаться с голым EFI без CSM. В остальном хозяин-барин.

Лично я не вижу причин не использовать EFI везде, где это только возможно.

Я не вижу разницы в этом плане между виртуальными и реальными машинами. Своп, если нужен, то в любом случае раздел, хотя можно и в файл. /tmp и /var/lock должны быть в отдельном разделе хотя бы для того, чтобы монтировать их как nosuid и noexec для безопасности. Правда, они могут быть tmpfs, но тогда нужен swap. /var надо монтировать как минимум nosuid, а если при инсталляции пакетов в /var ничего не запускается, то и noexec (в debian и клонах /var нельзя делать noexec). /home как минимум должен быть nosuid, а если ты не программист и не используешь tor, который устанавливается в домашний каталог, то и noexec. Ну и ещё при переустановке системы отдельный /home можно сохранить, хотя на виртуалке это, наверно, не так актуально.

половина в треде не поняли вопроса. вопрос не в отдельных дисках, а создании partion table.

Re:

Не создавай. Разрешение получено.

Своп, если нужен, то в любом случае раздел

swap можно писать в файл или в zvol на ZFS, например. Причём его размер можно выбирать и менять по ходу работы, а не ограничиваться фиксированной разметкой раздела.

Своп, если нужен, то в любом случае раздел

Обоснование будет? Он в любом случае работает в обход фс.

вопрос не в отдельных дисках, а создании partion table.

Я это и имел в виду.

swap можно писать в файл или в zvol на ZFS, например.

В zvol, как я понял, тоже отдельный раздел. А про файл знал и оговорился о нём, хотя сам использую традиционный своп == ram*2, что бы там ни говорили о том, что сейчас это не нужно.

А в файл можно tmpfs писать? И сбрасывать в него всю память в режиме гибернации, а потом восстанавливать её при загрузке?

Своп, если нужен, то в любом случае раздел

Обоснование будет?

Обоснование чего?

Он в любом случае работает в обход фс.

Какая разница? Всё равно это раздел. Раздел не обязан быть размеченным.

zvol, как я понял, тоже отдельный раздел

zvol — это не раздел. это блочное устройство выделяемое из какого-то пула. (например пула физических дисков)
в этом разница между ZFS и всем остальным. тебе не нужно «нарезать» устройство на разделы фиксированного размера чтобы получить точку монитрования ради noexec\etc
а завтра понять, что нарезал не очень удачно, и теперь места не хватает, т.к. раздел фиксирован и его нужно ресайзить.

сам использую традиционный своп == ram*2

отвратительное староверство.

Лично я не вижу причин не использовать EFI везде, где это только возможно.

коллаборационист?

А в файл можно tmpfs писать?

tmpfs может вытесняться в swap. swap может находиться в файле.

zvol — это не раздел. это блочное устройство выделяемое из какого-то пула. (например пула физических дисков)
в этом разница между ZFS и всем остальным. тебе не нужно «нарезать» устройство на разделы фиксированного размера чтобы получить точку монитрования ради noexec\etc

Спасибо за инфу. Надо будет почитать об этом.

сам использую традиционный своп == ram*2

отвратительное староверство.

Почему? На сегодня пара десятков гигов на диске — копейки. Зато у меня всегда есть куда выгрузить неиспользуемые страницы памяти, ту же tmpfs, а потом ещё и перейти в спящий режим.

tmpfs может вытесняться в swap. swap может находиться в файле.

Спасибо за инфу. Я об этом догадывался, но спросил потому, что tmpfs-разделы могут быть примонтированы до /home, в котором лежит swap-файл.

А что с поддержкой восстановления состояния после спящего режима из файла?

А как чекнуть диск без разделов на наличие ФС?