/rpool/ROOT/pve-1: 100% / -- was tun?

[whiterabbit]

Hi.
Nun ist das passiert, was nicht passieren darf:
Der ZFS-Pool des PVE-Hosts ist voll gelaufen:

root: #  zfs list
NAME                           USED  AVAIL     REFER  MOUNTPOINT
rpool                          108G     0B      104K  /rpool
rpool/ROOT                     107G     0B       96K  /rpool/ROOT
rpool/ROOT/pve-1               107G     0B     99.5G  /
rpool/data                     160K     0B       96K  /rpool/data

Daher zwei Fragen:

• Warum wird das bei ZFS nicht verhindert, wenn das Überschreiten von 80% schon als kritisch gilt?
• Wie kann ich etwas löschen (copy on write)? Ich hatte ein ISO aus /var/lib/vz/template/iso gelöscht -- das hat aber nichts gebracht; es bleibt bei 100%.

 

[whiterabbit]

ich habe mir jetzt mit

dpkg --list | grep -P -o "pve-kernel-\d\S+" | grep -v $(uname -r | grep -P -o ".+\d")

geholfen und ein paar alte Kernel entfernt ... das ging zum Glück; hatte schon befürchtet, dass Schluss ist, wenn das ZFS komplett voll gelaufen ist?!

Die erste Frage bleibt aber...

 

[Dunuin]

Daher zwei Fragen:

• Warum wird das bei ZFS nicht verhindert, wenn das Überschreiten von 80% schon als kritisch gilt?

Da muss man selbst für sorgen. Am besten ein Monitoringtool installieren und damit unter anderem ZFS überwachen lassen und täglich einmal draufgucken oder besser noch eMail-Benachrichtigungen konfigurieren. Sollte man ja eh, falls mal ein Laufwerk ausfällt oder sonst etwas mit dem Pool nicht stimmt.
80% ist noch nicht kritisch, geht aber auf die Leistung. Problematisch wird das eher so ab grob 90%.

• Wie kann ich etwas löschen (copy on write)? Ich hatte ein ISO aus /var/lib/vz/template/iso gelöscht -- das hat aber nichts gebracht; es bleibt bei 100%.

Wenn man etwas bei ZFS löscht wird das wegen CoW nicht sofort gelöscht. Am besten sicherstellen, dass da keine Snapshots existieren (sonst wird ja nichts gelöscht wenn der Snapshot das Löschen verhindert) und selbst dann kann es noch Minuten oder Stunden dauern, bis da ZFS den Platz wieder freigibt.
Ggf kann es auch nicht schaden einmal fstrim -a laufen zu lassen, um sicherzustellen, dass da auch wirklich alles einmal mit discard freigegeben wurde.

 

[whiterabbit]

Hallo.

Am besten ein Monitoringtool installieren

checkMK läuft hier zwar -- aber das Problem ist gestern Nacht während eines Backups aufgetaucht. Da konnten dann auch kein Lock-Dateien mehr angelegt werden, weil kein Platz mehr war. Daher ist (auch) das Backup schief gegangen und hat das Dateisystem scheinbar in einem r/o-Zustand hinterlassen??
Was da nun letztlich so plötzlich so viel Platz eingnommen hat, weiß ich nicht -- nachdem ich die alten Kernel entfernt und den PVE-Host neu gestartet habe, ist die Lage jetzt wieder ganz entspannt: nur noch 21% sind belegt!!

Am besten sicherstellen, dass da keine Snapshots existieren (sonst wird ja nichts gelöscht wenn der Snapshot das Löschen verhindert)

Snapshots existieren tatsächlich. Der von gestern Nacht hat tatsächlich ordentlich reingehauen -- der davor liegt im MB-Bereich.

rpool/ROOT/pve-1@zfs-auto-snap_daily-2020-12-26-0547                 42.2G

Wenn man etwas bei ZFS löscht wird das wegen CoW nicht sofort gelöscht

Ach so -- ich hatte es bisher immer so verstanden, dass uU gar nichts mehr gelöscht werden kann, WEIL auch nichts mehr geschrieben werden kann!?

 

[Dunuin]

ZFS arbeitet ja mit einem baumartigen Journal wo alle Änderungen als neue Daten immer weiter drangehängt werden. Wenn aber keine Snapshots das Löschen verhindern, dann kann ZFS auch alte nicht mehr gebrauchte Journaleinträge löschen bzw zusammenführen. Das dauert halt nur etwas und ist ziemlich komplex, besonders wenn da ZFS kaum Platz zum jonglieren der Daten auf den Platten hat.

Du könntest auch versuchen da per ZFS Attribute die Quotas so zu setzen, dass da alle Datasets und Zvols zusammen nie ganz den Pool füllen könnten. Falls du Angst hast, dass da eine Aktion wieder plötzlich den kompletten Pool vollschreibt.