Speicher komplett voll, Dienste starten nicht mehr

SoJo_BCS

New Member
Dec 10, 2024
2
0
1
Hallo zusammen,

ich stehe hier gerade vor einem kleinen Problem bei unserem Proxmox Server. Bei der Einrichtung wurde ein großes ZFS (insgesamt 15 HDDs á 10 TB) gespannt. Anfang der Woche ist eine Festplatte ausgefallen und wurde ausgetauscht, zu dem Zeitpunkt bestand allerdings schon kein Zugriff mehr auf den Server. Nach dem Austausch ist das Resilvering durchlaufen lassen, es besteht weiterhin kein Zugriff und es wird der komplette Speicher als voll angezeigt:
1778232073280.png
Snapshots sind keine vorhanden, die Speicherplatz belegen könnten. Logdateien sind auch alle schon gekürzt. Discard ist bei den VM-Disks leider nicht aktiviert.

Die Dienste starten aufgrund des nicht vorhandenen Speicherplatzes nicht, Zugriff über SSH besteht derzeit leider auch nicht, deswegen bin ich auf eine KVM vom Rechenzentrum angewiesen.
In meiner Verzweifelung habe ich auch schon in der /sys/module/zfs/parameters/spa_slop_shift den Wert von 5 auf 6 geändert, aber siehe Ausgabe oben. Der Screenshot entstand nach der Ausführung des Befehls (und einem Reboot weil zuerst keine Änderung ersichtlich war).

Habt ihr noch Tipps für mich, wie ich nun am besten vorgehen kann? Respektive, was braucht ihr noch für weitere Informationen um eventuell Tipps geben zu können?

Viele Dank im Voraus schonmal!
 
Vielleicht kannst du ja hiermit etwas zum löschen finden.
Bash:
du -shc /* | sort -h
du -shc /bigdirectory/* | sort -h
du -shc /bigdirectory/.../* | sort -h
apt clean und apt autopurge kann auch helfen.
Du kannst den spa_slop_shift Wert auch etwas weiter erhöhen. Zum Thema discard siehe auch hier. Und um das zu vermeiden hier.

Ich würde mich noch für die Ausgabe hiervon interessieren
Bash:
df -hT
lsblk -o+FSTYPE,LABEL,MODEL
zfs list -ospace,reservation,refreservation,quota,refquota
zpool status -v
 
Last edited:
Mit su -shc ist leider nichts übrig, was ich tatsächlich noch löschen könnte.

Das einfügen von der Ausgabe der anderen Befehle als Code haut leider die komplette Formatierung durcheinander (ist aber der Tatsache geschuldet, dass ich gerade nicht direkt aus der Shell wegkopieren kann), deswegen doch die Screenshots.

df -hT:
1778247732240.png


lsblk -o+FSTYPE,LABEL,MODEL
1778248537757.png1778248670020.png

zfs list -ospace,reservation,refreservation,quota,refquota
1778248777641.png

zpool status -v
1778248792299.png



Ich hatte vorhin auch schonmal den Scrub gestartet, das (repairing) ist allerdings erst zwischendurch irgendwann mal aufgetaucht.

Also... Läuft bei mir
 
Mir fallen hier mehrere Möglichkeiten ein, mir gefallen sie aber alle irgendwie nicht so. Falls du Backups für deine VMs hast, kannst du eventuell ZVOLs löschen bzw. verkleinern, ZB. das von VM 100, und die nach dem discard/fstrim später wiederherstellen?
Bash:
# Beides destruktiv
zfs set volsize=1M rpool/data/vm-100-disk-0
zfs destroy zfs/vm-102-disk-0
 
Last edited:
wirkt als sei deine root-Partition voll.
Mit einem beherzten ncdu -x / kannst du Speicherfresser sehr übersichtlich anzeigen.
Musst du wahrscheinlich mittels apt nachinstallieren.

P.S.: Dein root verfügt über satte 4GB. Wundert mich nicht, das es wie angezeigt voll ist.
P.P.S: Während der Installation eines PVE werden, sicherlich üppige, 100GB vorgeschlagen. Mit welchem Antrieb man die auf 4GB bei verfügbaren 120TB eindampft, erschließt sich mir nicht. Selbige rootpartition sollte man gerade mit ZFS vergrößern können, da kann ich aber leider nichts verlässliches beitragen. Volles root ist Kategorie: Houston wir haben ein Problem.
 
Last edited:
0% (bzw. GB in df -h) frei in "/" und wie jeder zfs user weiß wird zum Löschen Platz gebraucht. Deswegen Notfallreservierung verringern und nicht vergrößern, um an den letzten freien Platz ranzukommen:
echo 2 > /sys/module/zfs/parameters/spa_slop_shift
Nach dem Löschen wieder auf 5 setzen.
vm-102-disk-3 mit 110TB ... wer macht denn sowas ? Ist Schuld an deinem Dilemma.
 
Last edited:
Falls die VM alle noch kein Discard für ihre Disks aktiviert haben, wäre dann die Gelegenheit das einzustellen und im jeweiligen OS sollte das natürlich auch aktiviert sein. Wenn die VM wirklich z. B. 110TB Daten speichern, wie VM 102, wirds allerdings schwierig.
 
Last edited:
  • Like
Reactions: Johannes S
Ist die 2 ein Tippfehler? Das würde doch den reservierten Speicher auf 1/4 der Poolgröße erhöhen.
Was sagt denn die Doku zu dem Parameter ? Bin mir "eigentlich" ziemlich sicher, daß das so mal funktioniert hat, nachdem ich einen pool mal absichtlich zum Test vollgeschrieben habe und so damit dann wieder zum Leben bekommen habe ...
 
Statt Doku lesen hilft auch einfach probieren. Im derzeitegen Status geht nix, SoJo_BCS hat spa_slop_shift auch schon von 5 auf 6 geändert und wenn er so nicht löschen kann, auf 2 setzen und sehen ob es dann geht. Warum lange denken, geht eh nix mehr dran kaputt als es schon ist ?!
Laut link "Normally, the last 3.2% (1/(2^<span>spa_slop_shift</span>)) of pool space is reserved ..." --> je größer spa_slop_shift Wert ist, desto kleiner das Ergebnis der Formel bzw. der reservierte Bereich ... was theo. für Löschplatz sprechen würde ..., aber einfach probieren.
 
Ich habe in meinen Links von #2 sogar eine schöne Übersicht welcher spa_slop_shift Wert wie viel Prozent ergibt.
Auf discard bin ich dort ebenso eingegangen und ohne Platz kann man auch kein ncdu installieren weswegen ich du vorgeschlagen habe.
4G ist die belegte Größe und da nichts mehr übrig ist zeigt df hier vermutlich deswegen halt als Größe ebenfalls 4G an. Man sieht im Bild ja auch die Fehlende Quota dafür. df nutzt man für ZFS ja generell nicht unbedingt. Ich wollte mir nur einen Überblick damit verschaffen.
 
Last edited:
Also für ncdu benötigt man 120Kb.
In /boot/ lümmeln auch gerne alte Kernel rum. Die kann man auch manuell entfernen. (Anleitungen siehe Inet).
I.d.R sind immer zwei Kernel vorhanden.
Ein entfernter Kernelsatz bringt ca 100Mb.
 
Ganz klar.
Darum mein genereller Verweis aufs Inet um sich umfassend selbst zu informieren, bevor man anfängt zu Fuß nach einem von mir angeführtem Kochrezept am Bootmechanismus rumzufummeln.
So war ich mir z.B. nicht sicher, ob man auch ein grub-update durchführen sollte.

Gut dass du nochmal auf lauernde, fatale Folgen hinweist!
 
Last edited:
  • Like
Reactions: Johannes S