Чи потрібен LVM таблиці розділів?

Виявляється, я в змозі успішно виконати pvcreate над необмеженим блоковим пристроєм, не зробивши жодного кроку створення таблиці розділів. Тоді я можу створити групу томів, логічний том і, нарешті, файлову систему, змонтувати її та протестувати через dd.

Це, здається, працює, але мені потрібна перевірка обґрунтованості. Це погана ідея?

Як створити таблицю розділів GPT або MBR поверх необмеженого блокового пристрою?

Як використати проділ, щоб показати, який тип таблиці розділів використовується? Я намагався робити:

розлучається, вибирає / dev / sdb, друкує і отримую:

Помилка: / dev / sdb: нерозпізнана мітка диска

Але привід зараз використовується, і я можу його читати і писати. Це очікуваний вихід при виконанні LVM поверх необробленого блокового пристрою без таблиці розділів? Будь-які думки?

Спасибі!

Навіть якщо LVM сам не піклується про те, щоб мати реальний розділ, одна з причин створити його все одно - повідомити програми розділення, що там "щось є". Сценарій кошмару - це новий sysadmin, який діагностує проблему завантаження на сервері, запускає програму розділів, бачить нерозподілені диски та робить висновок про пошкодження накопичувача.

Я не бачу недоліків у створенні LVM-розділу. Чи ти?

У той час як ви можете просто створити ПВ із необробленого блокового пристрою, я зазвичай намагаюся уникати цього, оскільки це може спричинити плутанину щодо того, для чого використовується блок-пристрій. Він також може порушити деякі процедури автоматичного виявлення, які LVM може використовувати, якщо у ньому відсутні файли конфігурації.

Ось приклад використання розбитого для створення GPT з 1 розділом, який є усім диском, і встановлення прапора розділу на рівні lvm. Mkpart вимагає вказати файлову систему, але вона не створює файлову систему. Здається, що довго стоячи помилка в розставанні. Також стартовим зміщенням 1М є забезпечення правильного вирівнювання.

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 і додати його до групи томів. Таким чином, логічні томи гостя залишаються прихованими від гіпервізора.

Одним із недоліків є те, що не можна гарячим додати місця до ПВ всередині таблиці розділів. Це не проблема, якщо ви використовуєте весь блок пристрою для ПВ.

Згідно з посібником 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 (група томів), якщо ми не маємо намір включати лише його частини (розділ).

Навіть якщо в минулому я використовував MS-DOS disklabel або GPT disklabel для PV, я вважаю за краще використовувати безпосередньо LVM на основному блоковому пристрої. Немає ніяких причин використовувати 2 деклабелі, якщо тільки у вас немає конкретного випадку використання (наприклад, диск із завантажувальним сектором та завантажувальним розділом).

Перевагою прямого використання LVM є:

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