Czy LVM potrzebuje tablicy partycji?

Wygląda na to, że jestem w stanie z powodzeniem wykonać pvcreate na surowym urządzeniu blokowym, nigdy nie podejmując kroku tworzenia tabeli partycji. Jestem w stanie stworzyć grupę woluminów, wolumin logiczny i wreszcie system plików, zamontować go i przetestować przez dd.

Wygląda na to, że działa, ale potrzebuję kontroli poczytalności. Czy to zły pomysł?

Jak utworzyć tabelę partycji GPT lub MBR na surowym urządzeniu blokowym?

Jak użyć opcji parted, aby pokazać, jakiego rodzaju tablica partycji jest używana? Próbowałem zrobić:

parted, wybierz / dev / sdb, print i otrzymuję:

Błąd: / dev / sdb: nierozpoznana etykieta dysku

Jednak dysk jest obecnie używany i mogę na nim czytać i pisać. Czy to oczekiwane wyjście przy wykonywaniu LVM na surowym urządzeniu blokowym bez tablicy partycji? jakieś pomysły?

Dzięki!

Nawet jeśli sam LVM nie dba o prawdziwą partycję, jednym z powodów jej utworzenia jest poinformowanie programów partycjonujących, że „coś tam jest”. Scenariusz koszmaru to nowy administrator systemu diagnozujący problem z uruchomieniem na serwerze, uruchamiający program do partycjonowania, widziający dyski niepartycjonowane i stwierdzający, że dysk jest uszkodzony.

Nie widzę żadnych wad tworzenia partycji LVM. Czy ty?

Chociaż możesz po prostu stworzyć PV z surowego urządzenia blokowego, zwykle staram się tego unikać, ponieważ może to powodować zamieszanie co do tego, do czego urządzenie blokowe jest używane. Może również uszkodzić niektóre procedury automatycznego wykrywania, których LVM może użyć, jeśli brakuje jego plików konfiguracyjnych.

Oto przykład użycia parted do utworzenia GPT z 1 partycją, która jest całym dyskiem i ustawieniem flagi partycji na lvm. Program mkpart wymaga określenia systemu plików, ale nie tworzy systemu plików. Wydaje się być długotrwałym błędem w rozstaniu. Przesunięcie początkowe 1M ma zapewnić prawidłowe wyrównanie.

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

Jeśli utworzysz PV bezpośrednio na wirtualnym urządzeniu magazynującym wewnątrz gościa KVM, zauważysz, że woluminy logiczne od gościa są widoczne na hiperwizorze. Może to powodować zamieszanie, jeśli używasz tego samego logicznego woluminu i nazw grup woluminów dla wielu gości. Możesz również otrzymać ostrzeżenia na hiperwizorze informujące, że nie może znaleźć urządzenia.

Na przykład odtworzyłem ten problem na moim hiperwizorze testowym:

[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

Tutaj możesz zobaczyć 2 grupy woluminów o tej samej nazwie, obie od gości, które tak naprawdę nie powinny pojawić się na hiperwizorze.

Z tego powodu radziłbym najpierw użyć parted lub fdisk do utworzenia partycji KVM na nim (jak pokazano w poprzedniej odpowiedzi 3dinfluence), przed utworzeniem PV i dodaniem go do grupy woluminów. W ten sposób woluminy logiczne gościa pozostają ukryte przed hiperwizorem.

Jednym minusem jest to, że nie jest możliwe dodawanie miejsca na gorąco do PV wewnątrz tabeli partycji. Nie stanowi to problemu, jeśli używasz całego urządzenia blokowego do PV.

Zgodnie z przewodnikiem LVM RedHata, sekcja 4.2.1 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/physvol_admin

Powiedzieli, że nie ma potrzeby posiadania tablicy partycji, sugerują nawet, aby ją zniszczyć, jeśli użyjemy całego dysku dla VG (Grupa woluminów), chyba że zamierzamy uwzględnić tylko jego część (partycję).

Nawet jeśli w przeszłości korzystałem z etykiety dyskowej MS-DOS lub etykiety dyskowej GPT do PV, wolę teraz używać bezpośrednio LVM na głównym urządzeniu blokowym. Nie ma powodu, aby używać 2 etykiet dyskowych, chyba że masz bardzo konkretny przypadek użycia (np. Dysk z sektorem rozruchowym i partycją rozruchową).

Zaletą posiadania LVM bezpośrednio są:

• prostota - nie trzeba używać 2 zestawów narzędzi
• elastyczność - możesz używać pvmove do przenoszenia danych z jednego woluminu dysku na drugi bez przestojów, możesz użyć migawki i cienkiego przydzielania
• nie musisz uruchamiać partprobe ani kpartx, aby poinformować jądro, że utworzyłeś / zmieniłeś rozmiar / usunąłeś wolumin. A partprobe / kpartx może zawieść, jeśli partycje są w użyciu i może być konieczne ponowne uruchomienie
• być może lepsza wydajność w porównaniu do używania LVM na dyskach CD-MS-DOS lub GPT