staging.inyokaproject.org

Ich habe mir mal noch zwei Wochen Verlängerung gewährt. Ich möchte gerne ein richtiges Beispiel abbilden, muss dazu aber eine der VMs etwas umbauen und ein paar Mini-Festplatten erstellen. Inhaltlich sollte aber alles so korrekt sein.

Ich habe den Artikel mal kurz überflogen.

Es ist nicht möglich, die Größe der PEs nachträglich zu verändern. Dies ist aber auch nicht nötig,

Im LVM können alle Elemente außer der Größenzuweisung des „Physical Extent“ im laufenden Betrieb vergrößert und verkleinert werden.

Die PE Größe ist veränderbar, sofern es vom Alignment her passt (vgchange --physicalextentsize).

Die PE spielt im alltäglichen Gebrauch aber meistens gar keine Rolle, irgendwie reitet der Artikel zu sehr darauf herum.

Die zu verwendenden Partitionen / Festplatten müssen zunächst mittels pvcreate als „Physical Volume“ initialisiert werden.

Du kannst direkt vgcreate machen.

NAME
       vgcreate - Create a volume group

SYNOPSIS
       vgcreate position_args
           [ option_args ]

DESCRIPTION
       vgcreate creates a new VG on block devices. If the devices were not
       previously intialized as PVs with pvcreate(8), vgcreate will
       inititialize them, making them PVs. The pvcreate options for
       initializing devices are also available with vgcreate.

Für jedes Logical Volume wird eine Datei der Art /dev/GROUP/VOL und /dev/mapper/GROUP/VOL

/dev/mapper/group-vol und wenn - schon in den Namen waren wird -- daraus. Und das sind alles Links zum eigentlichen Devicemapper-Gerätenamen /dev/dm-<nummer>.

Zu modprobe & Co, die Module sollten eigentlich automatisch geladen werden... funktioniert das tatsächlich immer noch nicht?

Hallo,

Die PE spielt im alltäglichen Gebrauch aber meistens gar keine Rolle, irgendwie reitet der Artikel zu sehr darauf herum.

Kannst du gerne korrigieren. Kann schon sein, dass das ein historisches Artefakt im Artikel ist.

Gruß, noisefloor

frostschutz schrieb:

Die PE Größe ist veränderbar, sofern es vom Alignment her passt (vgchange --physicalextentsize).

Danke! Das probiere ich dann mit aus.

Die PE spielt im alltäglichen Gebrauch aber meistens gar keine Rolle, irgendwie reitet der Artikel zu sehr darauf herum.

Naja, die PE ist schon wichtig, weil daraufhin der Platz vergeben wird und die (Fehler-)Meldungen enthalten meist die Angaben in PE. Im alltäglichen Gebrauch spielt der ganze Artikel ja keine Rolle. Wenn es einmal eingerichtet ist, läuft es ja so nebenbei mit.
Oder meinst du, es wäre da besser die Größenänderungen und Snapshots zu behandeln, die man eher nutzt, und das Anlegen/Verwalten den Manpages zu überlassen?

Die zu verwendenden Partitionen / Festplatten müssen zunächst mittels pvcreate als „Physical Volume“ initialisiert werden.

Du kannst direkt vgcreate machen.

Meinst du im Beispiel? Bei vgcreate geht das, bei vgextend nicht und bei vorhandenen Partitionen auch nicht einfach so. Vllt sollte ich das deutlicher hervorheben.

/dev/mapper/group-vol und wenn - schon in den Namen waren wird -- daraus. Und das sind alles Links zum eigentlichen Devicemapper-Gerätenamen /dev/dm-<nummer>.

Danke! Da hab ich gepennt 😉

Zu modprobe & Co, die Module sollten eigentlich automatisch geladen werden... funktioniert das tatsächlich immer noch nicht?

Die Module zur Benutzung werden automatisch geladen, dm_mirror allerdings nicht. Braucht man ja auch eher selten bis nie. Ich habe den tatsächlich auch nur einmal verwendet — wegen des Artikels hier 😉

ChickenLipsRfun2eat schrieb:

Meinst du im Beispiel? Bei vgcreate geht das, bei vgextend nicht und bei vorhandenen Partitionen auch nicht einfach so. Vllt sollte ich das deutlicher hervorheben.

In der manpage sthet das auch für vgextend:

       If the specified PVs have not yet been initialized with pvcreate,
       vgextend will initialize them.

Es ist ja Geschmackssache wie man es macht. Fürs Verständnis sicher besser zu erklären, daß da ein PV erstellt wird. Ansonsten ist es halt ein Befehl weniger...

Naja, die PE ist schon wichtig, weil daraufhin der Platz vergeben wird und die (Fehler-)Meldungen enthalten meist die Angaben in PE.

Ja, stimmt.

Der Artikel ist schon ziemlich gut so.

frostschutz schrieb:

In der manpage sthet das auch für vgextend:

Ich probiere das einfach mal aus. Ich kann die frischen devices ja zuerst mit vgextend einbinden, dann wieder rauswerfen, klassisch partitionieren/formatieren und dann nochmal versuchen. Danke dir!

Ich habe drei neue Festplatten in die 18.04 VM eingebunden, mit je einer maximalen Kapazität von 2G.

Testplatte1 wurde mit gpt, 2 Partitionen und ext4 eingerichtet, um ein bestehendes Volume zu emulieren. 2 und 3 wurden unbearbeitet belassen.

Die bereits mit Partitionstabellen versehene Platte lässt sich nicht direkt mit vgcreate bearbeiten, auch nicht mit dem Schalter --force. pvcreate verhält sich da gleich. Beim Versuch die bestehenden ext4-Partitionen einzubinden weigert sich vgcreate ebenfalls. pvcreate bietet ein wipe des ext4-Systems an.

root@mate-kvm:~# vgcreate /dev/vdb /dev/vdc /dev/vdd
  /dev/vdb: already exists in filesystem
  Run `vgcreate --help' for more information.
root@mate-kvm:~# pvcreate /dev/vdb1 /dev/vdb2 /dev/vdc /dev/vdd
WARNING: ext4 signature detected on /dev/vdb1 at offset 1080. Wipe it? [y/n]: y
  Wiping ext4 signature on /dev/vdb1.
WARNING: ext4 signature detected on /dev/vdb2 at offset 1080. Wipe it? [y/n]: y
  Wiping ext4 signature on /dev/vdb2.
  Physical volume "/dev/vdb1" successfully created.
  Physical volume "/dev/vdb2" successfully created.
  Physical volume "/dev/vdc" successfully created.
  Physical volume "/dev/vdd" successfully created.
root@mate-kvm:~#

Das habe ich jetzt in meinen Text einfliessen lassen, allerdings ohne ausführliche Beschreibung. Ebenfalls ist damit der Warnhinweis bei pv/vgcreate hinfällig, da LVM nichts — oder nichts ohne Warnung macht. Ich teste das später noch mal unter 20.04, sollte sich da aber gleich verhalten.

Die PE lassen sich wirklich problemlos ändern, allerdings ist er ganz schön pingelig was die Größen angeht 😉 Am besten gibt man die in Bytes an. Ich hab das jetzt über vgchange --physicalextentsize $((128*faktor)) grp in ner Schleife ausprobiert.

ChickenLipsRfun2eat schrieb:

root@mate-kvm:~# vgcreate /dev/vdb /dev/vdc /dev/vdd
  /dev/vdb: already exists in filesystem
  Run `vgcreate --help' for more information.

vgcreate möchte als erstes Argument den Namen der Volume Group wissen, gefolgt von den Gerätenamen

USAGE
       vgcreate VG_new PV ...

du hast hier jedoch nur Gerätenamen übergeben, worüber sich vgcreate beschwert mit dem Hinweis /dev/vdb: already exists.

Ansonsten möchte ich an der Stelle noch anmerken, daß auf jede Festplatte eine Partitionstabelle gehört. /dev/sdx oder /dev/vdx direkt verwenden ist zwar technisch möglich aber keine gute Idee. Es gibt zu viele Programme (inkl. das BIOS selbst) die zuerst nach Partitionstabelle schauen und alles andere nicht oder falsch verstehen oder gar ungefragt eine Partitionstabelle anlegen und damit dann das unpartitionierte Dateisystem, LVM, RAID, LUKS etc. kaputt machen.

Wer sich die Partitionstabelle spart, riskiert damit Datenverlust.

Sorry, hab das falsche reinkopiert. Die korrekte Fehlermeldung lautet "Device /dev/vdb excluded by a filter.".

frostschutz schrieb:

Wer sich die Partitionstabelle spart, riskiert damit Datenverlust.

Interessanter Hinweis, danke! Das werde ich als Information mit aufnehmen, ist aber vermutlich auf Windows gemünzt? Ich habe mein Haupt-LVM seit Jahren auf „nackten“ Platten und bisher keine Probleme gehabt, auch nicht mit uefi/dual-boot (zwei Linuxe allerdings, die beide das selbe LVM nutzen).

Ich habe mir das 18.04 MATE noch mal neu, inkl. hwe-Kernel, aufgesetzt. Jetzt werden auch die Kernelmodule alle automatisch bei Bedarf nachgeladen (dm_snapshot und dm_mirror). Lag wohl am upgrade von 16.04 oder ähnlichem, daher sind die Kernelmodule nur noch in der Problembehebung beschrieben. frostschutz Hinweise und Verbesserungen sollten auch alle drin sein. Ich werde den Artikel dann nächste Woche noch mal mit einem 20.04 durchspielen.

Falls jemand noch eine hübsche Grafik beisteuern möchte, die LVM mit klassischer Partitionierung vergleicht, so dass die zusätzliche Ebene klar wird, wäre ich dankbar. Ich bekomme das nicht hin.

/edit: Ich wäre soweit fertig, 20.04 funktioniert absolut identisch. Testinstallation war eine MBR-Installation mit nachträglich installiertem lvm2 und den bereits verwendeten Testvolumes. Da ich beim Lesen schon etwas betriebsblind bin, möge sich noch jemand dessen annehmen und drübergucken. Danke!

ChickenLipsRfun2eat schrieb:

/edit: Ich wäre soweit fertig, 20.04 funktioniert absolut identisch. Testinstallation war eine MBR-Installation mit nachträglich installiertem lvm2 und den bereits verwendeten Testvolumes. Da ich beim Lesen schon etwas betriebsblind bin, möge sich noch jemand dessen annehmen und drübergucken. Danke!

Da das edit vllt nicht ausgereicht hat: Ich habe fertig 😉

pling 😉

Da ich sowieso gerade im Wiki rumwerke: Was fehlt(e) hier noch?

Hallo,

Danke für die Erinnerung. Artikel ist wieder im Wiki, Danke für die Überarbeitung ☺

Gruß, noisefloor