Nur 13GB statt 250. Was ist hier los?
Ich habe ja einen Backupserver mit Proxmox und zfs installiert und habe mir gedacht, dass das Ganze recht einfach gegangen ist. Nur nach einem unerwarteten Stromausfall (Corpus Delicti mein Finger, denn ich habe die falsche Funkstromsteckdose ausgeschaltet…) war auf einmal nur noch noch wenige Gigabyte Speicher vorhanden. Wieso? Keine Ahnung. Beim Installieren habe ich eigentlich – so bilde ich es mir zumindest ein – nichts falsch gemacht. Aber wer weiß? Auf jeden Fall schaut es jetzt sehr mager aus und der verfügbare Platz scheint auch immer mehr zu schrumpfen, local hat überhaupt nur mehr 1GB:
Und local-zfs ein bisserl mehr:
Beide verbindet jedoch die unwohl machende Tatsache, dass der Platz immer geringer wird. Auch der Outputs von zpool list und …
zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 12.5G 11.1G 1.38G - - 79% 88% 1.00x ONLINE -… zfs list …
zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 11.1G 1018M 104K /rpool
rpool/ROOT 1.76G 1018M 96K /rpool/ROOT
rpool/ROOT/pve-1 1.76G 1018M 1.76G /
rpool/data 9.35G 1018M 96K /rpool/data
rpool/data/vm-100-disk-0 9.35G 1018M 9.35G -
rpool/var-lib-vz 96K 1018M 96K /var/lib/vz… verheißen nichts Gutes, der Mini-Speicherplatz ist komplett fragmentiert und viel ist auch nicht mehr frei. Laut lsblk wird nur ein kleiner Teil der eigentlich ausreichend großen NVMe-Platte genutzt:
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sr0 11:0 1 1024M 0 rom
zd0 230:0 0 32G 0 disk
├─zd0p1 230:1 0 1M 0 part
├─zd0p2 230:2 0 512M 0 part
└─zd0p3 230:3 0 31.5G 0 part
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 1007K 0 part
├─nvme0n1p2 259:2 0 1G 0 part
└─nvme0n1p3 259:3 0 13G 0 partMöglicherweise hängt das alles mit dem “Stromausfall” zusammen, aber wenn man sich die Statistik aus dem Screenshot oben ansieht, war das Problem von Anfang an (13. Oktober) vorhanden und damit wohl despektierlich: PEBCAK. Also noch einmal neu aufsetzen, oder Partition erweitert? Ich glaube ich werde zuerst letzteres versuchen. Mit etwas Prise Hoffnung kann man auch darauf bauen, dass ich das File-System dann nicht mehr selbst auffrisst. Zur Not muss ich das System halt noch einmal neu aufsetzen. Die TrueNAS-VM sichere ich aber lieber noch einmal vorher.
VM-Backup auf Samba-Share speichern
Zum Glück habe ich ein Samba-Share, das ich für solche Zwecke verwenden kann. Ich habe zwar auch noch mein richtiges Backup-NFS-Netzlaufwerk, aber die ganzen Linux-Permissions einzurichten freut mich jetzt nicht, vor allem, da ja nachher vielleicht wieder alles weg ist.
Das Backup wird dann problemlos übers 1 Gbit-Netz geschoben, was auch nicht zu lange dauert:
Mit fdisk Partition erstellen und auf das zfs-Wunder hoffen?
Als nächstes erstelle ich eine neue Partition auf der NVMe-Platte mit dem Befehl fdisk /dev/nvme0n1:
Hier wird man zurecht gewarnt, doch nicht im laufenden Betrieb an der Platte herumzupfuschen. Daher werde ich doch lieber das Ganze von einem Live-USB-Stick booten und so die Partitionsgröße ändern und den Pool erweitern.
Live-USB-Stick to the rescue!
Dank PiKVM ist das Unterfangen jedoch relativ einfach und ich muss den Server nicht zum Bildschirm tragen:
Ich versuche es einmal mit Clonezilla, aber bei meinen letzten Versuchen habe ich eigentlich immer mehr Erfolg mit einer klassischen Linux Mint Live-Version gehabt. Aber schauen wir einmal.
Normal Boot:
Und Standardeinstellungen:
Ah, jetzt weiß ich wieder warum mir ein normales System lieber ist:
Woher soll ich denn jetzt wissen, was ich da auswählen soll? Ich möchte ja nur die bestehende Partition vergrößern…
Irgendwie habe ich gerade keine Nerven mich da durchzuprobieren. Weg mit Clonezilla, her Linux Mint!
Gefällt mir schon besser:
Und mit GParted sieht man auch gleich was los ist:
Irgendwie will er mich rpool nicht vergrößern lassen:
Das funktioniert anscheinend nicht mit GParted und überhaupt ist das mit zfs so eine Sache. Leider gehen die verschiedenen Seiten im Internet davon aus, dass man mehrere Festplatten hat und nicht nur eine. Aber ich glaube ich habe technisch gesehen einen RAID-(un)Verbund.
Mit sudo parted /dev/nvme0n1 print schauen was da ist:
Dann mit resizepart 3 61440MB auf 60GiB erweitern und dann noch gleich einen weiteren Pool für die VMs und Container machen:
Gleich kommt der Moment der Wahrheit, und ob ich Proxmox in Bälde neu installieren darf. Auf zum Neustart!
Proxmox lebt noch
Die gute Nachricht: Proxmox lebt noch…
… und ich kann versuchen das zu vervollständigen. Der Befehl lsblk zeigt schon den vergrößerten rpool:
root@backup:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sr0 11:0 1 1024M 0 rom
zd0 230:0 0 32G 0 disk
├─zd0p1 230:1 0 1M 0 part
├─zd0p2 230:2 0 512M 0 part
└─zd0p3 230:3 0 31.5G 0 part
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 1007K 0 part
├─nvme0n1p2 259:2 0 1G 0 part
├─nvme0n1p3 259:3 0 56.2G 0 part
└─nvme0n1p4 259:4 0 181.3G 0 part Mit zpool online -e rpool /dev/nvme0n1p3 sollte man expandieren können, es tut aber nichts. Auch Autoexpand will nicht so recht:
root@backup:~# zpool set autoexpand=on rpool
root@backup:~# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 12.5G 11.1G 1.37G - 43G 79% 89% 1.00x ONLINE -Vielleicht hilft ja ein Neustart.
Nein hilft nicht.
Notlösung VM verschieben und mit 12 GiB leben
Ich habe als eine Art Notlösung jetzt einfach die VM auf den neuen vmpool verschoben…
… und werde halt mit nur 12 GiB leben:
Auch zpool list scheint wieder zufriedener zu sein:
root@backup:~# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
rpool 12.5G 1.77G 10.7G - 43G 6% 14% 1.00x ONLINE -
vmpool 181G 9.36G 172G - - 0% 5% 1.00x ONLINE -
Auch wenn ich jetzt nicht weiß was mit dem “EXPANDSZ” ist, und ob ich jemals diese “43G” zurückbekommen werde.
Ich habe aber jetzt nicht wirklich die Motivation, die ganze Installation noch einmal machen (und dann eh wieder die ganze Festplatte auswählen), nur um das gleiche Problem noch einmal zu haben. Mit 11 GB ist man zwar etwas schmal bedient aber was soll’s, das wird sich schon ausgehen, vor allem wenn ich zusätzliche Container/VMs, derer es nicht viele geben wird, auf dem vmpool verweilen lassen werde.