LVM-Volumes unter Linux vergrößern und verkleinern

Nach dem Einrichten meiner LVM-Volumes war auf der SSD noch Platz übrig. Das war kein Rechenfehler. Ich wollte gerade nicht alles sofort verteilen, denn ich weiß heute noch nicht, ob in zwei Jahren Docker, Matrix oder ein ganz anderer Dienst mehr Speicher braucht.

Nun ist genau das der angenehme Teil von LVM: Ein Logical Volume lässt sich recht einfach vergrößern. Beim Verkleinern sieht die Sache anders aus. Dort kann ein falscher Schritt Daten abschneiden, und das ist wörtlich gemeint.

Wie viel Platz ist überhaupt noch frei?

Zuerst schaue ich mir die Volume Groups und Logical Volumes an:

sudo vgs
sudo lvs

Bei vgs interessiert mich vor allem VFree. Danach prüfe ich noch einmal den Mountpoint, den ich verändern will:

findmnt /var/lib
df -h /var/lib
sudo lvs -o lv_name,vg_name,lv_size,devicesCode-Sprache: JavaScript (javascript)

So sehe ich nicht nur die Namen, sondern auch, welches Volume wirklich hinter /var/lib steckt. Gerade bei ähnlich benannten Volumes ist das keine überflüssige Runde.

Mein ext4-Volume vergrößern

Das Volume /dev/vgssd/varlib hat bei mir 150 GB. Sollen 50 GB dazukommen, kann ich zunächst nur das Logical Volume erweitern:

sudo lvextend -L +50G /dev/vgssd/varlib
sudo resize2fs /dev/vgssd/varlib

Der erste Befehl vergrößert das LV, der zweite das ext4-Dateisystem darin. Bequemer geht beides in einem Schritt:

sudo lvextend -L +50G -r /dev/vgssd/varlib

Die Option -r lässt LVM das unterstützte Dateisystem gleich mit anpassen. Soll ein Volume den gesamten noch freien Platz seiner Gruppe bekommen, nutze ich eine Prozentangabe:

sudo lvextend -l +100%FREE -r /dev/vg0/srv

Das ist bei meinem alten HDD-Verbund interessant. Sobald die dort nicht mehr benötigten System-Volumes weg sind, kann /srv den frei gewordenen Platz erhalten.

Verkleinern ist keine umgedrehte Vergrößerung

Bei ext4 muss das Dateisystem zum Verkleinern ausgehängt sein. Außerdem gilt eine Reihenfolge, die man nicht vertauschen darf: erst das Dateisystem, danach das Logical Volume. Würde ich zuerst das LV kleiner machen, könnte ich den hinteren Teil des Dateisystems einfach abschneiden.

Ein beispielhafter Ablauf für ein Test-Volume sieht so aus:

sudo umount /dev/vgssd/example
sudo e2fsck -f /dev/vgssd/example
sudo resize2fs /dev/vgssd/example 80G
sudo lvreduce -L 80G /dev/vgssd/example

Das ist absichtlich nur ein Beispiel. Vorher prüfe ich mit lsblk -f das Dateisystem und habe ein aktuelles, getestetes Backup. XFS etwa lässt sich vergrößern, aber nicht verkleinern. Dort braucht man für weniger Platz in der Regel ein neues Dateisystem und kopiert die Daten hinüber.

Warum ich freien Platz nicht als Verschwendung sehe

Früher hätte ich wahrscheinlich versucht, die SSD bis auf das letzte Gigabyte aufzuteilen. Heute gefällt mir der nicht zugewiesene Platz besser. Wächst /var/lib, bekommt Docker mehr. Wird Matrix größer, kann ich /matrix erweitern. Ich muss nur dann entscheiden, wenn ich auch echte Zahlen habe.

Das Vergrößern werde ich deshalb bei Bedarf direkt nutzen. Ein Volume kleiner machen würde ich dagegen nur mit Ruhe, Wartungsfenster und einer Rückfallebene. Wie haltet ihr das: verteilt ihr eine neue Volume Group sofort komplett oder bleibt bei euch ebenfalls etwas frei?

LVM unter Linux – die Serie

• Teil 1: Was ist LVM und welche Vorteile hat es?
• Teil 2: LVM einrichten und Logical Volumes erstellen
• Teil 3: LVM-Volumes vergrößern und verkleinern
• Teil 4: Alte LVM-Volumes sicher löschen und Speicher freigeben