Нужна ли LVM таблица разделов?

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

Похоже, что работает, но мне нужно проверить работоспособность. Это плохая идея?

Как создать таблицу разделов GPT или MBR поверх необработанного блочного устройства?

Как использовать parted, чтобы показать, какая таблица разделов используется? Я пытался сделать:

parted, выберите / dev / sdb, распечатайте и я получу:

Ошибка: / dev / sdb: нераспознанная метка диска

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

Благодарность!

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

Я не вижу недостатков в создании раздела LVM. Вы?

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

Вот пример использования parted для создания GPT с 1 разделом, который является целым диском, и установкой флага раздела lvm. Mkpart требует, чтобы вы указали файловую систему, но она не создает файловую систему. Кажется, давняя ошибка в parted. Кроме того, начальное смещение 1M должно обеспечить правильное выравнивание.

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on

Если вы создадите PV непосредственно на виртуальном устройстве хранения в гостевой системе KVM, то вы заметите, что логические тома из гостевой системы видны на гипервизоре. Это может привести к путанице, если вы используете одинаковые имена логических томов и групп томов для нескольких гостей. Вы также можете получить некоторые предупреждения на гипервизоре о том, что он не может найти устройство.

Например, я воссоздал эту проблему на моем тестовом гипервизоре:

[root@testhost ~]# vgs
  Couldn't find device with uuid dCaylp-1kvL-syiF-A2bW-NTPP-Ehlb-gtfxZz.
  VG          #PV #LV #SN Attr   VSize   VFree  
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_testhost   1   8   0 wz--n- 237.98g 120.15g

Здесь вы можете увидеть 2 группы томов с одинаковыми именами, которые не должны отображаться в гипервизоре.

По этой причине я бы посоветовал вам сначала использовать parted или fdisk для создания там раздела KVM (как показано в предыдущем ответе 3dinfluence), прежде чем создавать PV и добавлять его в группу томов. Таким образом, гостевые логические тома остаются скрытыми от гипервизора.

Недостатком является невозможность горячего добавления пространства в PV внутри таблицы разделов. Это не проблема, если вы используете все блочное устройство для PV.

Согласно руководству LVM от RedHat, раздел 4.2.1 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/physvol_admin

Они сказали, что нет необходимости иметь таблицу разделов, они даже предлагают нам ее уничтожить, если мы используем весь диск для VG (Volume Group), если только мы не собираемся включать только его части (раздел).

Даже если в прошлом я использовал метку диска MS-DOS или метку диска GPT для PV, сейчас я предпочитаю использовать непосредственно LVM на главном блочном устройстве. Нет смысла использовать 2 метки диска, если только у вас нет особого варианта использования (например, диск с загрузочным сектором и загрузочный раздел).

Преимущество наличия LVM напрямую:

• простота - вам не нужно использовать 2 набора инструментов
• гибкость - вы можете использовать pvmove для перемещения данных с одного дискового тома на другой без простоя, вы можете использовать моментальный снимок и тонкую настройку
• вам не нужно запускать partprobe или kpartx, чтобы сообщить ядру, что вы создали / изменили размер / удалили том. И partprobe / kpartx может дать сбой, если разделы используются, и вам может потребоваться перезагрузка
• возможно, лучшая производительность по сравнению с использованием LVM поверх дисков MS-DOS или GPT