4. Spezialitäten unter LVM

Neben dem Vorteil der abstrakten Speicherverwaltung bietet LVM2 einige Spezialitäten an. Mit Snap Shots kann der Datenzustand logischer Volumen temporär eingefroren werden, was besonders bei einer Datensicherung von Dateien von Vorteil sein kann. Zusätzlich sind Raid ähnliche Funktionen verfügbar. Logische Volumen können gespiegelt oder als Stripe Set über mehrere physikalische Volumen verteilt werden. Auch wenn damit weder Raid-Controller oder Softwareraid zu ersetzen sind, kann diese Funktionalität den administrativen Alltag gelegentlich vereinfachen.

Snapshots für logische Volumen

Snapshots ermöglichen, im laufenden Betrieb ein Zustandsabbild eines logischen Volumen einzufrieren. Dieses ist schnell eingerichtet, benötigt gegenüber einem Image wenig zusätzlichen Speicher in der Volumengruppe und ist für die Anwender völlig transparent. Das originale logische Volumen funktioniert hierbei weiterhin wie gewohnt, sodass der Anwender keine Änderung feststellen wird. Das bedeutet, er kann weiterhin Dateien anlegen, löschen oder ändern und alle Operationen werden scheinbar wie immer durchgeführt. Über das Snapshot steht allerdings der Datenstand zum Zeitpunkt des Einfrierens zur Verfügung. Leider überdauert ein Snapshot keinen Neustart des Servers und ist nicht für die forensische Sicherung geeignet. Für eine dateikonsistente Datensicherung im laufenden Betrieb oder zur Synchronisation ist es ideal geeignet.

Snapshots werden in der Volumengruppe als Volumen angelegt und mit dem zugehörigen logischen Volumen verbunden. Über die zugehörige Gerätedatei kann auf den Datenstand des betreffenden Volumens zum Zeitpunkt der Snapshot-Erstellung zugegriffen werden. Beim Erstellen ist die Speichergröße eines Puffers anzugeben, in dem alle Änderungen, die von den Anwendern beim Arbeiten an den physikalischen Verwaltungseinheiten durchführen werden, landen. Die Puffergröße ist für die geplante Lebensdauer des Snapshot ausreichend zu dimensionieren. Bei der Festlegung der Snapshotgröße ist es wichtig zu beachten, dass die Arbeitsgranularität der Größe der physikalischen Verwaltungseinheiten entspricht. Wird der Platz knapp, lassen sich Snapshots mit den entsprechenden Werkzeugen zur Volumengrößenänderung vergrößern. Läuft der reservierte Puffer über, wird das betreffende Snapshot automatisch aufgelöst und alle Änderungen ins logische Volumen übertragen. Dieses gilt auch, wenn das Snapshot manuell vom Administrator aufgelöst wird.

 Snap Shot

Im Beispiel wird für das linear angelegte Volumen ein Snapshot erzeugt und getestet. Hierbei kommen die bereits bekannten Werkzeuge „lvcreate“ zum Erstellen des Snapshot-Volumens, „lvresize“ zur Größenänderung des Volumens und „lvremove“ zum Auflösen des Snapshots zum Einsatz.

debian:~# lvs
  LV        VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  lv-linear vg01 -wi-ao 150,00M
  lv-stripe vg01 -wi-ao 400,00M
debian:~# echo "Hallo Welt" > /mnt/linear/test.txt
debian:~# lvcreate -s -n snap -L 20m /dev/vg01/lv-linear
  Logical volume "snap" created
debian:~# lvs
  LV        VG   Attr   LSize   Origin    Snap%  Move Log Copy%  Convert
  lv-linear vg01 owi-ao 150,00M
  lv-stripe vg01 -wi-ao 400,00M
  snap      vg01 swi-ao  20,00M lv-linear   0,04
debian:~# mkdir /mnt/snap
debian:~# mount /dev/vg01/snap /mnt/snap
debian:~# df /mnt/*
Dateisystem          1K Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg01-lv--linear
                        148799      1551    139568   2% /mnt/linear
/dev/mapper/vg01-snap
                        148799      1551    139568   2% /mnt/snap
/dev/mapper/vg01-lv--stripe
                        396672      2318    373874   1% /mnt/stripe

Im ersten Schritt zeigt der Status die augenblickliche Konfiguration der Volumen an. Das betreffende logische Volumen ist an den Mountpoint „/mnt/linear“ gebunden, hier wird ein Text in eine Testdatei geschrieben. Jetzt wird das Snapshot für das Volumen erzeugt. Das Werkzeug „lvcreate“ erhält hierfür dir Option „-s“ und das Argument, für welches bestehende logische Volumen das Snapshot angelegt werden soll. Das Snapshot bekommt eine Größe von 20Mb und hört auf den Namen „snap“. Der danach abgerufene Volumenstatus listet das Snapshot auf. Aus der Auflistung geht neben der Größe, auch die prozentual verbrauchte Speichermenge und der Name des originalen Volumens, an den das Snapshot gebunden ist, hervor. Um das Snapshot zu testen, wird der Mountpoint „/mnt/snap“ angelegt und das Snap-Volumen mit diesem montiert. Die Auflistung der montierten Volumen offenbart gleiche Werte für das Originalvolumen unter „/mnt/linear“ und das Snap-Volumen unter „/mnt/snap“. Als Unterschied ist das Snap-Volumen nicht beschreibbar eingebunden, sodass über den betreffenden Mountpoint keine Änderungen vorgenommen werden können.

debian:~# lvdisplay vg01/snap
  --- Logical volume ---
  LV Name                /dev/vg01/snap
  VG Name                vg01
  LV UUID                u1X8oj-Y6HR-Bomy-rzeW-LF7h-WcGw-vW8IB1
  LV Write Access        read/write
  LV snapshot status     active destination for /dev/vg01/lv-linear
  LV Status              available
  # open                 1
  LV Size                150,00 MB
  Current LE             75
  COW-table size         20,00 MB
  COW-table LE           10
  Allocated to snapshot  0,12%
  Snapshot chunk size    4,00 KB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:2

Im nächsten Schritt wird der Inhalt der vorher angelegten Testdatei geändert, was über die Ausgabe der Datei bestätigt wird. Über das montierte Snap-Volumen ist aber weiterhin der alte Stand zum Zeitpunkt der Erstellung des Snapshots abrufbar. Aus diesem Grund eignen sich Snapshots hervorragend für transparente Datensicherungen auf Dateibasis, von denen der Anwender nichts mitbekommen soll. Die Ausgabe des Volumenstatus bestätigt, dass sich der Speicherverbrauch auf dem Snap-Volumen erhöht hat. Die geänderten Informationen sind damit im Puffer des Snap-Volumens abgelegt worden.

debian:~# echo "Hallo du schöne Welt" > /mnt/linear/test.txt
debian:~# cat /mnt/linear/test.txt
Hallo du schöne Welt
debian:~# cat /mnt/snap/test.txt
Hallo Welt
debian:~# lvs
  LV        VG   Attr   LSize   Origin    Snap%  Move Log Copy%  Convert
  lv-linear vg01 owi-ao 150,00M
  lv-stripe vg01 -wi-ao 400,00M
  snap      vg01 swi-ao  20,00M lv-linear   0,12

Erweiterte Information über das Snap-Volumen liefert das Werkzeug „lvdisplay“. Hier sind der Status und das Zielvolumen inklusive der Stammdaten des Zielvolumens wie Größe und Anzahl der logischen Verwaltungseinheiten abrufbar. Die Funktionalität des Snapshots erfolgt durch das Mappen geänderter Information. Dieses verwaltet das Snap-Volumen über die COW-Tabelle, ihr steht hierfür der reservierte Speicherplatz zur Verfügung. Der verfügbare Speicher wird in der Tabelle über Chunks verwaltet, die in der Beispielkonfiguration eine definierte Größe von 4kb haben. Das bedeutet, Änderungen werden mit einer Granularität von 4kb abgelegt und verwaltet. Die Chunk-Größe kann beim Anlegen des Snapshots festgelegt werden und als gute Wahl gilt die Blockgröße des darüberliegenden Dateisystems, das häufig eine Blockgröße von 4kb aufweist. Bei der vorherigen Änderung hat sich der Speicherverbrauch um 0,08% erhöht, was einer Größe von 16kb oder vier Chunks entspricht. Die vorgenommene Änderung ist mit Sicherheit kleiner als 1kb, aber warum wurden vier Chunks aus dem knappen SnapShot Speicher verwendet? Die Antwort ist ganz einfach. Das über das Volumen gelegte Dateisystem hat vier Änderungen durchgeführt. Zuerst hat es die neuen Daten im Dateisystem abgelegt und danach zum Erzeugen der neuen Datei eine Inode reserviert, was schon zwei Änderungen entspricht. Dann wurde der Verzeichniseintrag für die neue Datei erzeugt und mit der neuen Inode verknüpft, damit ist die Datei im Dateisystem verfügbar. Zum Schluss wurde die alte Inode, die auf die alten Daten zeigt, freigegeben und so der alte Inhalt gelöscht. Damit wurden vom Dateisystem vier Änderungen an unterschiedlichen Blöcken vorgenommen, die vom LVM in vier Chunks abgelegt wurden. Da LVM den verfügbaren Speicher transparent zur Verfügung stellt, besitzt es kein Wissen über den Aufbau und die Struktur des drüberliegenden Dateisystems. Es kann nur Änderungen in den Blöcken erfassen und diese mappen, den Sinn dieser Änderungen kann es nicht erfassen. Bei der Größenfestlegung des Snap-Volumens sollte dieses bedacht und ausreichend Platz vorgesehen werden. Fällt trotz der gewissenhaften Planung auf, dass der Platz im Snap-Volumen knapp wird, kann das Volumen ohne Probleme vergrößert werden. Läuft das Snap-Volumen über, wird dieses automatisch aufgelöst und die gemappten Änderungen werden in das Zielvolumen übertragen.

debian:~# lvresize -L 50m vg01/snap
  Extending logical volume snap to 50,00 MB
  Logical volume snap successfully resized
debian:~# lvs
  LV        VG   Attr   LSize   Origin    Snap%  Move Log Copy%  Convert
  lv-linear vg01 owi-ao 150,00M
  lv-stripe vg01 -wi-ao 400,00M
  snap      vg01 swi-ao  50,00M lv-linear   0,05

Für die Vergrößerung kommt das Werkzeug „lvresize“ zum Einsatz. Der Status zeigt an, dass die Vergrößerung wie beabsichtigt durchgeführt wurde und das Snap-Volumen ausreichend Platz zur Verfügung hat. Jetzt wird es Zeit das Snap-Volumen aufzulösen.

debian:~# umount /mnt/snap/
debian:~# lvremove vg01/snap
Do you really want to remove active logical volume "snap"? [y/n]: y
  Logical volume "snap" successfully removed
debian:~# cat /mnt/linear/test.txt
Hallo du schöne Welt

Vor dem Auflösen wird das Volumen vom Mountpoint getrennt und danach mit dem Werkzeug „lvremove“ aufgelöst. Bei diesem Vorgang wird eine interaktive Bestätigung abgefragt, die mit der Option „-s“ unterdrückt werden kann. Eine Prüfung der Datei bestätigt, dass die vorherige Änderung an der Datei beim Auflösen übernommen worden ist.

Logical Volumen mit Stripe Sets

Zur Geschwindigkeitssteigerung bietet LVM2 die Möglichkeit, logische Volumen als Stripe Set über mehrere physikalischen Volumen innerhalb einer Volumengruppe zu verteilen. Hierbei werden die Daten in Streifen geschnitten und gleichmäßig über die eingebundenen physikalischen Volumen verteilt. Die Konstellation entspricht hierbei einer RAID0-Konfiguration und bringt einen ähnlichen Leistungsschub, aber auch die bekannte Gefahr eines erhöhten Datenverlustes mit sich. Bei der Einrichtung des logischen Volumens sind die Anzahl und Größe der Streifen anzugeben, in die die Daten geschnitten werden sollen. Hierbei ergibt sich die maximale Anzahl aus der Anzahl der zugeordneten physikalische Volumen in der Volumengruppe. Die Größe der Streifen kann zwischen 8KB und 256KB festgelegt werden und kann in Abhängigkeit der durchschnittlichen Dateigröße die Leistung beeinflussen. Wie beim RAID0 kann hier, für eine ausgewogene Leistung eine Streifengröße von 64KB gewählt werden. Die Leistung wird sich hierbei um den Faktor der verteilten Streifen erhöhen. Die Ausfallwahrscheinlichkeit steigt ebenfalls um den Faktor der Streifen und der Ausfall eines physikalischen Volumens hat den Verlust des gesamten Datenbestandes im Stripe Set zur Folge.

  Logische Volumen mit Stripe Set

Ist für die Volumengruppe die Zuweisungsrichtlinie „normal“ aktiv, wird das Einrichten mehrerer Streifen auf nur einem physikalischen Volumen verweigert, da es zu einem starken Leistungseinbruch des Volumens führen würde. Soll dieses Verhalten erzwungen werden, muss für die Volumengruppe die Richtlinie „anywhere“ aktiviert werden.

Im Beispiel wird ein neues logisches Volumen als „Stripe Set“ über zwei physikalische Volumen angelegt. Im Anschluss wird die Leistung des Volumens ermittelt und mit der Leistung des linearen Volumens verglichen.

debian:~# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  vg01   1   1   0 wz--n- 976,00M 826,00M
debian:~# pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sdb1  vg01 lvm2 a-   976,00M 826,00M
  /dev/sde1       lvm2 --   977,86M 977,86M
debian:~# vgextend vg01 /dev/sde1
  Volume group "vg01" successfully extended
debian:~# lvcreate -i2 -I64 -L400m -n lv-stripe /dev/vg01
  Logical volume "lv-stripe" created
debian:~# pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sdb1  vg01 lvm2 a-   976,00M 626,00M
  /dev/sde1  vg01 lvm2 a-   976,00M 776,00M
debian:~# vgs
  VG   #PV #LV #SN Attr   VSize VFree
  vg01   2   2   0 wz--n- 1,91G 1,37G
debian:~# lvs
  LV        VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  lv-linear vg01 -wi-a- 150,00M
  lv-stripe vg01 -wi-a- 400,00M

Im ersten Schritt wird der Status der Volumen und der Volumengruppen ermittelt. Die Volumengruppe „vg01“ verfügt über ein physikalisches Volumen. Sie wird um das physikalische Volumen „/dev/sde1“ erweitert, das noch ungenutzt zur Verfügung steht. Nach der Erweiterung wird das logische Volumen „lv-stripe“ in der Volumengruppe „vg01“ mit einer Größe von 400Mb angelegt. Das Volumen wird als Stripe Set über 2 Streifen mit einer Streifengröße von 64Kb aufgeteilt. Die Statusabfrage zum Abschluss bestätigt die Erweiterung der Volumengruppe und die Nutzung der physikalischen Volumen.

debian:~# mkdir /mnt/stripe
debian:~# mke2fs /dev/vg01/lv-stripe
mke2fs 1.41.3 (12-Oct-2008)
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=1024 (log=0)
Fragmentgröße=1024 (log=0)
102400 Inodes, 409600 Blöcke
20480 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=1
Maximale Dateisystem-Blöcke=67633152
50 Blockgruppen
8192 Blöcke pro Gruppe, 8192 Fragmente pro Gruppe
2048 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken:
        8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409

Schreibe Inode-Tabellen: erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt

Das Dateisystem wird automatisch nach jeweils 20 Einhäng-Vorgängen bzw.
alle 180 Tage Überprüft, je nachdem, was zuerst eintritt. Veränderbar mit
tune2fs -c oder -t .
debian:~# mount /dev/vg01/lv-stripe /mnt/stripe

Im zweiten Schritt wird ein Mountpoint angelegt, das logische Volumen mit einem ext2 Dateisystem versehen und auf dem Mountpoint montiert.

debian:~# df /mnt/*
Dateisystem          1K Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg01-lv--linear
                        148799      1550    139569   2% /mnt/linear
/dev/mapper/vg01-lv--stripe
                        396672      2318    373874   1% /mnt/stripe
debian:~# free
             total       used       free     shared    buffers     cached
Mem:         28852      27616       1236          0       1568      11968
-/+ buffers/cache:      14080      14772
Swap:       979924       8296     971628

Vor dem Leistungsvergleich werden noch einmal die Daten abgefragt. Beide Dateisysteme sind im Verzeichnisbaum montiert und haben die eingerichtete Größe. Als Arbeitsspeicher stehen dem System nur ca. 32Mb zur Verfügung. Das ist wichtig, da nicht benutzter Speicher vom Betriebssystem automatisch als Cache verwendet wird, was das Messergebnis verfälschen würde.

Für den Test kommt das Werkzeug „Bonnie++“ zum Einsatz, das ggf über die Paketverwaltung nachinstalliert werden muss. Als Erstes wird das lineare Volumen mit 130Mb getestet. Hierbei treten die Schwächen der eingesetzten USB-Speicher zutage, die sich insbesondere bei einem Vergleich der Schreib- zur Leserate zeigen. Beim blockweisen Lesen kommt das Volumen auf ca. 16Mb/Sek, beim Schreiben auf ca. 1.5Mb/Sek

debian:~# bonnie++ -d /mnt/stripe/ -s 130m -u 0
Using uid:0, gid:0.
Writing with putc()...done
Writing intelligently...done
Rewriting...done
Reading with getc()...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
debian         130M  2482  17  2745   1  2038   1 13354  81 30828   8 108.7   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2383  86 +++++ +++  8614  14  1538  52  9459 100 10839 100

Im letzten Abschnitt wird das Stripe Set Volumen getestet. Hier zeigt sich gegenüber dem linearen Volumen nahezu eine Verdoppelung der Lese- und Schreibraten. Das war zu erwarten, können die Daten doch gleichzeitig über zwei physikalische Volumen weggeschrieben werden. Interessant ist hierbei der Einbruch beim zufälligem Erzeugen von Daten und der gleichbleibende Wert beim Löschen zufällig angelegter Daten. Diese Werte könne mit der hohen Prozessor-Auslassung beim Zugriff auf die USB-Speicher im Zusammenhang stehen.

Abschließend kann festgehalten werden, dass das Stripe-Set wie erwartet funktioniert, die Schreib- und Leseleistung verbessert und dass USB-Flash-Speicher nicht wirklich als leistungsstarke Speicherlösung zu gebrauchen sind. Die Technik lässt sich gut einsetzen, um nachträglich mehr Leistung für ein Dateisystem bereit zustellen. Generell ist es aber besser für ein solches Unterfangen den Unterbau des physikalischen Volumens mittel Software RAID einzurichten. Dieses kann bei der Erweiterung eines Servers auch nachträglich durch den Umzug der physikalischen Verwaltungseinheiten erfolgen und der Leistungsschub kommt hierbei allen logischen Volumen in der Volumengruppe zugute.

Logische Volumen mit Spiegelung

Zum Erhöhen der Ausfallsicherheit biete LVM die Möglichkeit der vereinfachten Spiegelung logischer Volumen an. Hierbei wird ein lineares logisches Volumen als Master angelegt, das automatisch auf ein oder mehrere Spiegelvolumen repliziert wird. Die Volumengruppe muss für die Anwendung über ausreichende physikalische Volumen verfügen, da jedes in der Spiegelung angelegte Volumen auf einem eigenen physikalischen Volumen abgelegt wird. Für die Spiegelung verwendet LVM eine eigene Granularität, die „Regio“ genannt wird und als Standardwert eine Größe von 512kb enthält. Dieser Wert entspricht der normalen Sektorgröße von blockorientierten Datenträgern. Damit die Laufwerksleistung nicht eingeschränkt wird, sollten alle eingebunden physikalischen Volumen die gleiche Sektorgröße besitzen und die Regiogröße sollte auf diese Sektorgröße eingestellt sein. In der Vergangenheit war dieses kein Problem, da die Sektorgröße bei Festplatten aus Tradition 512kb betrug. In der Zukunft werden die Hersteller diese Größe auf 4kb anheben, da sie so die Speichergröße moderner Festplatten halbwegs kompatible erhöhen können. Physikalische Volumen mit unterschiedlichen Sektorgrößen führen beim Laufwerk mit den 4kb Sektoren zu einem vierfach höheren Overhead, was diese Platte extrem ausbremsen wird. Die von den Herstellern angebotene 512kb Emulation ist keine Abhilfe, da sich an der Problematik nichts ändert und sie nur gegenüber dem Betriebssystem verschwiegen wird. Die Regiogröße kann beim Anlegen mit der Option „-r“ angepasst werden. Die Replizierung erfolgt immer vom Mastervolumen auf die Slavevolumen und der augenblickliche Status der Regios wird in einem Log festgehalten. Für dieses Log gibt es zwei Ablageformen. Als Standard wird dieses in einem eigenen Volumen abgelegt, was in der Volumengruppe ein weiteres physikalisches Volumen benötigt. Damit sind in der Volumengruppe für ein Volumen mit einem Spiegel und einem Volumenlog, drei physikalische Volumen notwendig. Als Alternative kann das Log im Speicher angelegt werden. Hierbei geht das Log beim Ausschalten des Systems verloren und LVM ist der aktuelle Status der Regios nicht bekannt. Als Folge wird es das gesamte Mastervolumen auf die Slavevolumen replizieren, was bei großen Volumen zu einem Leistungseinbruch während der Replikation führt.

Im Beispiel wird ein logisches Volumen als Spiegelvolumen mit einer Kapazität von 50Mb eingerichtet und bereitgestellt.

debian:~# pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sdb1  vg01 lvm2 a-   976,00M 626,00M
  /dev/sde1  vg01 lvm2 a-   976,00M 776,00M
debian:~# vgs
  VG   #PV #LV #SN Attr   VSize VFree
  vg01   2   2   0 wz--n- 1,91G 1,37G
debian:~# lvs
  LV        VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  lv-linear vg01 -wi-ao 150,00M
  lv-stripe vg01 -wi-ao 400,00M

debian:~# lvcreate -L 50 -m1 --corelog -n mirror-core vg01
  Logical volume "mirror-core" created

debian:~# lvs
  LV          VG   Attr   LSize   Origin Snap%  Move Log Copy%  Convert
  lv-linear   vg01 -wi-ao 150,00M
  lv-stripe   vg01 -wi-ao 400,00M
  mirror-core vg01 mwi-a-  50,00M                         40,00
debian:~# vgs
  VG   #PV #LV #SN Attr   VSize VFree
  vg01   2   3   0 wz--n- 1,91G 1,27G
debian:~# pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sdb1  vg01 lvm2 a-   976,00M 576,00M
  /dev/sde1  vg01 lvm2 a-   976,00M 726,00M
debian:~# lvdisplay vg01/mirror-core
  --- Logical volume ---
  LV Name                /dev/vg01/mirror-core
  VG Name                vg01
  LV UUID                e9TrkM-qYGC-Tysv-gnMH-EZ0D-lMvs-Hjgou9
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                50,00 MB
  Current LE             25
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:4

Im ersten Schritt wir der Status der Volumen ausgegeben und geprüft, dass die Volumengruppe bereits über zwei physikalische Volumen verfügt und das auf beiden physikalischen Volumen noch ausreichend Platz für zwei Volumen vorhanden ist. Danach wird ein neues logisches Volumen als Spiegelvolumen eingerichtet. Das Werkzeug „lvcreate“ bekommt dafür die Option „-m“ mit der Anzahl der anzulegenden Volumenspiegel übergeben. Eine nachträgliche Prüfung, der Volumen zeigt, dass das neue Volumen angelegt und der notwendige Speicher auf beiden physikalischen Volumen reserviert wurde. Dass es sich hierbei um einen Spiegel handelt, kann man nur den Attributen der Ausgabe des Werkzeugs „lvs“ entnehmen.


wiki/seminare/workshops/lvm2/wst04.txt · Zuletzt geändert: 2011-12-20 22:20 von Marek Walther