Datastore 100% voll, nach manuellem löschen werden ausstehende Daten nicht entfernt.

Jul 3, 2024
37
2
8
Germany
Hallo liebe Gemeinde,

ich hatte den Fall, dass mein Datastore zu 100% vollgelaufen ist. In diesem Zustand ließ sich weder GC noch Prune manuell ausführen.
Also habe ich die Backups einiger VMs manuell gelöscht (aus dem Inhalt) und dann die Aufbewahrungsregeln reduziert (nur 1 Monat statt 3, nur 4 Wochen statt 6).

Manuell ausgelöste Prune-Jobs laufen normal.
Manuell ausgelöster Garbage Collect Job auch. Dieser zeigt dann Daten entfernt : 0 B, Ausstehende Daten : 7,47 TB.

Die ausstehenden Daten werden einfach nicht entfernt, was zu vollem Datastore führt.

Hat jemand eine zielführende Lösung für mich ?

Version des PBS : 4.1.1 - 1 Kernel 6.14.11-4-pve

Grüße

Mike
 
Der GC löscht nicht sofort. Siehe auch hier. Wo befindet sich dein Datastore? Kannst du folgendes teilen?
Bash:
lsblk -o+FSTYPE,LABEL,MODEL
df -hT
Die kompletten Task Logs wären auch sinnvoll.
 
Last edited:
  • Like
Reactions: Johannes S
Der GC löscht nicht sofort. Siehe auch hier. Wo befindet sich dein Datastore? Kannst du folgendes teilen?
Bash:
lsblk -o+FSTYPE,LABEL,MODEL
df -hT
DIe kompletten Task Logs wären auch sinnvoll.
Das relevante ist wahrscheinlich das : rpool/datastore-small zfs Size: 9,8T, Used : 9,8T, Avail 90GB Mounted on /mnt/datastore-small

In der GUI steht bei Datastore - SMALL-8x1.9 (so heißt der Datastore) unter Garbage-Collect-Jobs - Ausstehende Daten 7,47TB

@news : Wie bekomme ich heraus, wie lange die Wartezeit ist ?
 
Wie bekomme ich heraus, wie lange die Wartezeit ist ?
cutoff 1d 5m, minimum access time is 2026-03-02T06:04:55Z
Änderbar in Datastore > Options > Tuning Options.

1772529224727.png
Bitte nicht raus picken was von einer Befehlsausgabe relevant sein könnte, das hilft meist nicht. Oder die Ausgabe weitgehend stehen lassen.
Werden die GC Jobs denn regelmäßig nach dem prune ausgeführt? Zb. täglich.
Ein kleiner Tipp noch wie man bei ZFS einen vollen Storage verhindert und was man tun kann falls es doch passieren sollte.
 
Last edited:
  • Like
Reactions: Johannes S and news
Änderbar in Datastore > Options > Tuning Options.

View attachment 96263
Bitte nicht raus picken was von einer Befehlsausgabe relevant sein könnte, das hilft meist nicht. Oder die Ausgabe weitgehend stehen lassen.
Werden die GC Jobs denn regelmäßig nach dem prune ausgeführt? Zb. täglich.
Ein kleiner Tipp noch wie man bei ZFS einen vollen Storage verhindert und was man tun kann falls es doch passieren sollte.
Zur Relevanz : Naja, die anderen Ausgabezeilen beziehen sich auf andere Mounts bzw ein weiteres Datastore. Kann mir nicht vorstellen, was da noch hilfreich wäre
:)

Die Tuning options habe ich gesehen, die stehen bei mir genau so drin, außer Threads bei Verifizierung : 4 und Anzahl der verifizierenden Threads : 16.

Der Server ist etwas leistungsfähiger....

Was ich nicht weiß: welche Auswirkungen haben die Einträge für cut-Off und Cache genau ? Kann ich die guten Gewissens ändern ?
Vielleicht temporär, dann GC Job laufen lassen und dann wieder zurück ?

Ich will einfach nur zügig die ausstehenden Daten weg haben.
 
Siehe meinen Link von #3 der erklärt wieso das überhaupt existiert. Das temporör zu ändern ist die Idee, ja. Ob das für deinen Fall sicher ist kann ich dir aber nicht beantworten.
 
  • Like
Reactions: Johannes S
Siehe meinen Link von #3 der erklärt wieso das überhaupt existiert. Das temporör zu ändern ist die Idee, ja. Ob das für deinen Fall sicher ist kann ich dir aber nicht beantworten.
Ja, ich habe den Link gelesen - ich verstehe das so, dass Chunks erst dann richtig gelöscht werden, nachdem die Cutoff Zeit abgelaufen ist. Meiner Meinung ist sie das und trotzdem bleibt das Zeug stehen. Ich halbiere die Einträge mal temporär. Wenn es schiefgeht, sind die Backups eben weg, was in diesem Fall nicht viel Probleme macht.
 
So, kurzer Status : Ich habe die Einträge für Cutoff Time auf 725 und für Cache Capazity auf 0 gesetzt, Prune und GC laufen lassen und voila : Alles wurde sauber entfernt. Werte wieder auf Original gesetzt und alles ist wieder schick.

Danke für Eure Mitarbeit !
 
Hallo, ich setze mir immer auf meine ZFS Pools ein spezielles Quota mit
Code:
zfs get refreservation rpool/quota
#
zfs create rpool/<zfs-data-pool>
zfs set refreservation=<15% of max.> rpool/<zfs-data-pool>
Somit kann ich diesen Wert bei einem "Unfall" heruntersetzen und mein ZFS Pool arbeitet noch.
 
Last edited:
  • Like
Reactions: Johannes S
Wenn sowas passiert, dann verschiebe ich x-Dateien aus dem chunks-Ordner. Danach läuft GCP erfolgreich durch. Danach kopiere ich die verschoben chunks zurück.
 
Wenn sowas passiert, dann verschiebe ich x-Dateien aus dem chunks-Ordner. Danach läuft GCP erfolgreich durch. Danach kopiere ich die verschoben chunks zurück.
Kleiner Hinweis, wenn man das macht, bitte nicht das Livelog des Jobs öffnen. Da kommen so schnell so viele Fehlermeldungen wegen missing Chunks, dass dir deine GUI einfriert. Also entweder per CLI Monitoren oder einfach laufen lassen.
Natürlich sollte man wissen was man tut und alle Chunks nachher wieder an die gleiche Stelle moven.
 
  • Like
Reactions: Johannes S
Kleiner Hinweis, wenn man das macht, bitte nicht das Livelog des Jobs öffnen. Da kommen so schnell so viele Fehlermeldungen wegen missing Chunks, dass dir deine GUI einfriert. Also entweder per CLI Monitoren oder einfach laufen lassen.
Natürlich sollte man wissen was man tut und alle Chunks nachher wieder an die gleiche Stelle moven.
Gute Ergänzung bzgl. lauernden Fußangeln und mir völlig neu, denn ich bin noch nie auf so eine Idee gekommen.
Schon in Bugzilla gemeldet?
 
Last edited:
Warum? Das ist doch kein Bug, eigentlich sind solche Aktionen mit massenhaft Chunks verschieben ja nicht vorgesehen, sondern dass man darauf achtet, dass immer genug Platz vorhanden ist.
Ach? Den Laden lahmzulegen, nur weil Speicherplatz ausgeht ist kein Bug? Man hätte ja nur ordentliche Quotas setzen müssen und workarounds sind schließlich nicht vorgesehen? Klingt ein wenig nach 5-Jahresplan der SED.
Jungs, das kann doch nicht euer Ernst sein.
Diese Problematik taucht hier seit Jahren auf,

Selbiges MUSS systemintern in JEDEM FALL ABGEFANGEN werden!
 
Last edited:
Ach? Den Laden lahmzulegen, nur weil Speicherplatz ausgeht ist kein Bug? Man hätte ja nur ordentliche Quotas setzen müssen und workarounds sind schließlich nicht vorgesehen? Klingt ein wenig nach 5-Jahresplan der SED.
Das kann doch nicht euer Ernst sein.
Diese Problematik taucht hier seit Jahren auf,

Selbiges MUSS systemintern in JEDEM FALL ABGEFANGEN werden!
Das Problem ist aber auch, nicht jeder hat richtig Ahnung von ZFS. Auch Quota setzen kann schief gehen. Ich habe schon Systeme gesehen da war eine Quota gesetzt, aber da derjenige nicht verstanden hatte, dass die Poolkapazität Brutto ist und man den RaidZ Verschnitt noch abziehen muss, war die Quota zu groß gewählt gewesen.
Solche Fehler passieren immer wieder und deshalb ist es hilfreich den Leute Tipps an die Hand zu geben wie man aus dem Problem wieder raus kommt.
Der Lerneffekt ist dann auf jeden Fall da und den Leuten passiert das nicht mehr.
 
Sag ich doch.
Darum so ein trivialer Tipp, chunks zu verschieben, damit eine GC ihre Arbeit tun kann um Platz zu schaffen.
Warum achtet ein PBS nicht auf den verfügbaren Speicher, bevor er platt ist?
Egal ob ZFS oder sonstwas.
 
Sag ich doch.
Darum so ein trivialer Tipp, chunks zu verschieben, damit eine GC ihre Arbeit tun kann um Platz zu schaffen.
Warum achtet ein PBS nicht auf den verfügbaren Speicher, bevor er platt ist?
Egal ob ZFS oder sonstwas.
Bei jedem anderen FS kannst du ja noch löschen. XFS z.B. reserviert ja direkt Speicher für solche Operationen. Klar könnte man eine generelle Quota einführen bei z.B. 98%. Das müsste dann mal jemand im Bugzilla verewigen.