[linux-l] LVM: wie gejht dat?

[Steffen Dettmer]

* Roland Penzin wrote on Mon, Dec 30, 2002 at 03:10 +0100:
> Am Samstag, 28. Dezember 2002 12:08 schrieb Steffen Dettmer:
> > Und wo ist nun Dein Problem?!
> 
> ahem, also, eigentlich,... hatte ich gehofft, das ich dich in einem 
> moment erwische, wo du bock hast in 5 sätzen das ding (LVM) zu 
> beschreiben, so dass ich anschliessend verstehe, was in den howtos 
> gemeint ist.
> du hast die fähigkeit, in wenigen sätzen das wesentliche auszudrücken, 

Ich?! Wow, thx.

Schlomo hat das ja prima beschrieben. Klingt vielleicht bißchen
kompliziert. Zunächst, die PEs sind erstmal eher uninteressant.
Kann man sich wie ne künstliche Clustergrenze vorstellen. Platten
kann man ja auch nicht auf's byte genau Partionieren. Ich stell
mir das immer wie ne virtuelle Platte vor.

Man hat also erstmal Partionen (oder ganze Platten, aber wie
gesagt, ich würde Partionieren, wegen dem Umschieben, siehe
Beispiel). Also hat man da hda1 bis hdc4 oder sowas. Weil das
physikalisch ist (also auch für einen Windowsuser sichtbar),
nennen wir die mal nicht Partionen, sondern PVs, physikalische
Volumes. Die liegen da erstmal so rum.

Eigentlich wollen wir ja nu LVs, logische Volumes, schließlich
möchte man ja irgendwo auch mal ein Filesystem draufmachen.

Natürlich braucht so ein LV irgendwo physikalischen Speicher.
Hierfür haben wir ja schon ein paar PVs rumliegen. Nu kann aber
ein LV nicht nur aus meheren PVs bestehen, man kann auch zwei LVs
auf ein PV machen, oder 5 auf 3 oder was sonst noch so angesagt
ist. 

Also schmeißt man da noch fix was dazwischen, nennt sich
"Volumegroup" (VG) und müßte besser "physical volume group"
heißen. Ein VG ist einfach ne Sammlung von 1..n PVs, also ne
Menge von PVs (sprich: echte Partitionen). So eine VG ist so ein
bißchen was wie ne logische Festplatte. Ein VG ist ja einfach ein
Klumpen Speicher (der aus mehreren Unterklumpen bestehen kann).

So ne logische Festplatte kann man dann logisch "partionieren",
also in LVs unterteilen.  Hier kommt wieder der Punkt: ist
natürlich clever, seine logische Partion so zu bauen, daß die
logische Festplatte nicht über meherere physikalische welche
verstreut ist; wäre ja bißchen blöd, wenn so ein Ding dann
ausfällt --> fällt die ganze logische Platte (VG) aus, damit alle
logischen Partionen (LVs).

> dann ist da noch die frage der stabilität des ganzen,

Na ja, >1 bug je 1000 Zeilen, paar tausend Zeilen Kernelcode
hier, lieber nicht drüber nachdenken ;)

> also wenn man da ext3 mit aufträgt, ob das auch mal ein
> stromausfall, oder ein rechnerhänger überlebt..

Im Betrieb rechnet das LVM im westenlichen Addressen um (siehe
MMU [Memory Mangement Unit] Beispiel aus dem Thread hier). Da
wird nix zusätzlich gebuffert, also ändert sich hier erstmal nix.
ext3 und reiserfs kommen mit Stromausfall dank Journal ganz gut
hin, selbst bei großen Partionen (natürlich unabhängig von LVM).
Ich persönlich würde ext3 verwenden. Hab in der Praxis meist
reiserfs, weil ext3 ja noch nicht so lange fertig ist, das
funktioniert auch. Dank Tools wie vgscan (baut sich die VGs
automatisch), kann man dann also auch prima von RettungsCD aus
mounten, sowas finde ich immer wichtig. Ich hab meine TestSuSE
öfter mal resettet, hat geklappt, auch wenn ext3 dann hin- und
wieder doch noch ein fsck macht, ist wohl ein Feature. Ich hab
aber aus Zeitgründen nur kleine Dateien verwendet (100MB jeweils)
und die gegeneinander ge-cmp-t, hat immer gestimmt. Bei ext3
sollte man für's resizen unmounten, bei reiserfs geht das online,
also im gemounten Zustand. Bin mir daher noch unschlüssig, was
ich nehme, aber vermutlich dann lieber ext3 und RettungsCD, oder
mini-Linux auf Notpartion, sowas ist eh nett. ext3 kleiner machen
war damals auch noch nicht das, was man in der Produktion
verwenden sollte. Das ist vermutlich der Knackpunkt; es nützt ja
nix, mehr Platz zu haben, wenn das Filesystem das nicht kapiert.
Hier würde ich nochmal nachlesen, ob man ext3 inzwischen
problemlos verkleinern kann. Vielleicht braucht man das ja mal.

Laut meinen Tests merken die vg* Tools auch, wenn man Mist machen
möchte, z.B. ein PV zu zwei VGs hinzuzufügen oder sowas.

vgscan erkennt (findet) die konfigurierten PVs und VGs (!). 
vgdisplay -v sollte man sich noch merken, daß erzählt einem nach
einem vgscan den Rest. Steht alles da, was man wissen muß, finde
ich. Ich empfand das alles als liebevoll und gut benutzbar
gemacht. Anfangs muß man aufpassen, bei LVs, PVs und VGs und dem
ganzen Kram nicht durcheinander zu kommen. Einfach mal bißchen
mit rumspielen.

Ach so, jetzt kurz zu PE/LE. So ein LV kann sich auch automatisch
vergrößern. Finde das mometan unwichtig, weil ich glaube, die
Filesysteme können sich noch nicht automatisch vergrößern. Na ja,
vielleicht geht das. Hier kann man jedenfalls einstellen, wie
weit sich das dann vergrößert (also 4MB weise ist wohl default).
Noch ein Tipp: in einem VG immer bißchen Platz lassen, es also
nicht zu 100% ausnutzen. Mit dem freien Platz kann man dann
nämlich Snapshoots ziehen. Das ist prima für Backups. Einfach den
aktuellen Zustand als Snapshoot mounten (zwei Kommandos nur), und
dann den Snapshoot aufs Band, verify. Auch wenn das eigentliche
System geändert wird, beleibt der snapshot konstant. Nach dem
Backup schmeißt man den dann einfach weg. Bei Stromausfall
passiert auch nix schlimmes, klar, der Snapshoot ist weg, egal,
Backup ist eh hin, aber das eigentliche System stimmt. (bei
Snapshot werden die Daten vor dem Überschreiben nämlich in den
eigentlich freien Platz kopiert, und beim Lesen aus dem Snapshot
werden diese dann geliefert). Wenn der Platz (also díe VG) voll
ist, kannste den Snapshot auch wegschmeißen, klar. Dann macht man
den Kram einfach nochmal, und kopiert während des Backups dann
ein bißchen weniger ;)

Mist, so ne lange Mail wollte ich gar nicht schreiben.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.