LVM'nin bir bölüm tablosuna ihtiyacı var mı?


18

Bir bölüm tablosu oluşturma adımını atmadan, bir ham blok cihazının üstünde bir pvcreate başarıyla yapabileceğim anlaşılıyor. Daha sonra bir birim grubu, mantıksal birim ve son olarak bir dosya sistemi oluşturabilir, bağlayabilir ve dd ile test edebilirim.

İşe yarıyor gibi görünüyor, ama akıl sağlığı kontrolüne ihtiyacım var. Bu kötü bir fikir mi?

Ham blok aygıtının üstünde nasıl GPT veya MBR bölümleme tablosu oluştururum?

Ne tür bir bölümleme tablosunun kullanıldığını göstermek için ayrıştırmayı nasıl kullanabilirim? Yapmayı denedim:

ayrıldı, / dev / sdb seçin, yazdırın ve ben:

Hata: / dev / sdb: tanınmayan disk etiketi

Yine de sürücü şu anda kullanımda ve onu okuyabilir ve yazabilirim. Bir bölüm tablosu olmadan bir ham blok cihazının üstünde LVM yaparken beklenen çıktı mı? Düşüncesi olan var mı?

Teşekkürler!

Yanıtlar:


29

LVM'nin kendisi gerçek bir bölüme sahip olmakla ilgilenmese bile, yine de bunu oluşturmanın bir nedeni bölümleme programlarına "orada bir şey" olduğunu bildirmektir. Kabus senaryosu, bir sunucuda önyükleme sorununu tanıyan, bölümleme programını başlatan, bölümlenmemiş diskleri gören ve sürücünün bozuk olduğu sonucuna varılan yeni bir sistem yöneticisi.

LVM bölümü oluşturmanın hiçbir dezavantajı yok. Yapıyor musun?


1
Senaryo için +1. Gerçek hayatta çok muhtemel.
Hennes

1
Anlayışlı olduğu için +1.
Alexander Janssen

Cevap için teşekkürler! Kesinlikle bir bölüm tablosu olması hiçbir dezavantajı görmüyorum. Ben sadece akıl sağlığı kontrolüyle onaylamak istedim. Doğru katman sırası şöyledir: blok cihazı, bölüm tablosu, birim grubu, mantıksal birim, dosya sistemi, doğru mu?
kedi pantolonları

8
Dezavantajı: Blok cihazı genişletirseniz ve bir bölüm tablosu kullanmadıysanız, fiziksel birimi hemen pvresize ile genişletebilirsiniz. Bir bölüm tablosu kullandıysanız, önce bölümü silmeniz ve önce daha büyük boyutta yeniden oluşturmanız gerekir.
sciurus

1
Dikkatli davranmak iyidir, ancak soruyu geri atmak harika bir cevap vermez. Bu bölüme gerek yoktur ve bölüme sahip olmanın dezavantajları vardır.
bryn

16

Ham blok cihazdan sadece bir pv oluşturabilirken, normalde blok cihazının ne için kullanıldığına dair karışıklığa neden olabileceğinden bundan kaçınmaya çalışırım. Ayrıca, LVM'nin yapılandırma dosyaları eksikse kullanabileceği bazı otomatik bulma yordamlarını da kırabilir.

Burada, tüm sürücü olan 1 bölümlü bir GPT oluşturmak ve bölüm bayrağını lvm olarak ayarlamak için ayrıştırılmış kullanımına bir örnek verilmiştir. Mkpart bir dosya sistemi belirtmenizi gerektirir, ancak dosya sistemini oluşturmaz. Ayrılmış uzun bir hata gibi görünüyor. Ayrıca 1M'nin başlangıç ​​ofseti, doğru hizalamayı elde etmenizi sağlamaktır.

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

3
"Mkpart bir dosya sistemi belirtmenizi gerektiriyor, ancak dosya sistemini oluşturmuyor." Bu bahsettiğiniz için teşekkür ederiz, bu akıl sağlığı tesisinde BÜYÜK! :)
kedi pantolonları

1
Artık doğru değil. mkpart primary 1M 100%çalışır ve Dosya sistemi alanı boş bırakır.
stark

1
@ 3dinfluence lvm şimdi otomatik olarak hizalama yapıyor, uzun yıllar sonra lvm için belirtilen veri diski için bir bölüm kullanmak için gerçek kullanım durumunu görmüyorum
c4f4t0r

5

Doğrudan bir KVM misafirinin içindeki bir sanal depolama cihazında bir PV oluşturursanız, konuktan gelen mantıksal hacimlerin hipervizörde görülebildiğini göreceksiniz. Birden fazla konuk için aynı mantıksal cilt ve birim grubu adlarını kullanırsanız, bu durum oldukça kafa karıştırıcı olabilir. Ayrıca, hipervizörde bir cihaz bulamadığını söyleyen bazı uyarılar alabilirsiniz.

Örneğin, bu sorunu test hipervizörümde yeniden oluşturdum:

[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

Burada, her ikisi de hipervizörde gerçekten görünmemesi gereken misafirlerden aynı ada sahip 2 cilt grubu görebilirsiniz.

Bu nedenle, bir PV oluşturmadan ve bir hacim grubuna eklemeden önce (orada 3dinfluence tarafından önceki yanıtta gösterildiği gibi) bir KVM bölümü oluşturmak için ayrıştırılmış veya fdisk kullanmanızı öneririm. Bu şekilde, konuk mantıksal hacimleri hipervizörden gizli kalır.


1
filterDoğrudan VM'leriniz tarafından kullanılan tüm engelleme aygıtlarını filtrelemek için /etc/lvm/lvm.conf içinde kullanırsanız bu önlenebilir .
Mircea Vutcovici

Diskler her zaman ana bilgisayarda her zaman mevcuttur - bölümler eşlenmez. kpartx -abunu sizin için yapar. Hiper denetimcinin tüm konuk disklere erişimi vardır, ancak birim grupları etkinleştirilmemelidir.
bryn



3

Geçmişte PV için MS-DOS disk etiketi veya GPT disk etiketi kullanmış olsam bile, şimdi ana blok cihazında doğrudan LVM kullanmayı tercih ediyorum. Çok özel bir kullanım durumunuz yoksa (önyükleme sektörü ve önyükleme bölümü olan disk gibi) 2 disk etiketi kullanmak için hiçbir neden yoktur.

Doğrudan LVM'ye sahip olmanın avantajı:

  • basitlik - 2 takım araç kullanmanıza gerek yoktur
  • esneklik - pvmove kullanarak verileri bir disk biriminden diğerine kesinti olmadan taşımak için anlık görüntü ve ince temel hazırlık kullanabilirsiniz
  • çekirdeği bir birim oluşturduğunuzu / yeniden boyutlandırdığınızı / sildiğinizi söylemek için partprobe veya kpartx çalıştırmanız gerekmez. Ve partprobe / kpartx başarısız olabilir bölümleri kullanımda ise ve siz yeniden başlatma gerekebilir
  • MS-DOS veya GPT disk etiketlerinde LVM kullanımına kıyasla daha iyi performans

2
Neden herkesin bu bölümü istediğinden emin değilim - ama burada cevap "neden olmasın" yönünde gidiyor. Bu cevap daha iyidir - tüm diski kullanacaksanız bir bölüme ihtiyacınız yoktur. Bir bölüme sahip olmak, yeniden boyutlandırma / genişletme disklerini çok daha acı verici hale getirebilir.
bryn

Birçok unix sistem yöneticisi bu mantığı
linux'a getiriyor
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.