[SOLVED] PBS ZFS Datastor voll. Wie Speicher freigeben?

J

j_k

New Member
Proxmox Subscriber
Jul 5, 2023
5
1
3
Hallo zusammen,

wir betreiben einen PBS mit ZFS Datastor. Leider ist uns das ZFS vollgelaufen.

Ich habe bereits einige alte VM Backups und Namespaces via UI gelöscht und andere alte VM Backups per CLI gelöscht. Außerdem habe ich nach Recherche hier im Forum auch versucht ältere Verzeichnisse aus ./chunks/ auf einen anderen Datenträger zu verschieben. Pruning der Backups wurde ebenfalls dürchgeführt. Eigentlich hätten dabei einige GB zusammenkommen sollen. Leider hat nichts davon Speicherplatz recovered.. Weswegen die GarbageCollection nach wie vor fehlschlägt mit "no space left on device".
Datastore umounten sowie reboot zum freigeben evtl. offen gehalterner files welche die Speicherfreigabe verhindern könnten wurde auch gemacht. Leider ohne Erfolg.

Während meiner Recherche habe ich gelesen das man Quotas setzen sollte damit ein Dataset gar nicht erst zu 100% vollaufen kann. Das wird nachgeholt sobald es geht. Aber zuerst muss ich irgendwie Speicherplatz fregeben um wieder handlungsfähig zu sein.

Was kann ich in dem Fall noch tun? Habt ihr noch Ideen wie ich Speicherplatz freiräumen kann?

# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zstor 76.4T 76.3T 129G - - 77% 99% 1.00x ONLINE -
Click to expand...

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zstor 64.2T 0B 64.2T /mnt/datastore/zstor
Click to expand...

# zfs get all
NAME PROPERTY VALUE SOURCE
zstor type filesystem -
zstor creation Fri Aug 25 19:52 2023 -
zstor used 64.2T -
zstor available 0B -
zstor referenced 64.2T -
zstor compressratio 1.03x -
zstor mounted yes -
zstor quota none default
zstor reservation none default
zstor recordsize 128K default
zstor mountpoint /mnt/datastore/zstor local
zstor sharenfs off default
zstor checksum on default
zstor compression on local
zstor atime on default
zstor devices on default
zstor exec on default
zstor setuid on default
zstor readonly off default
zstor zoned off default
zstor snapdir hidden default
zstor aclmode discard default
zstor aclinherit restricted default
zstor createtxg 1 -
zstor canmount on default
zstor xattr on default
zstor copies 1 default
zstor version 5 -
zstor utf8only off -
zstor normalization none -
zstor casesensitivity sensitive -
zstor vscan off default
zstor nbmand off default
zstor sharesmb off default
zstor refquota none default
zstor refreservation none default
zstor guid 3522821261725458241 -
zstor primarycache all default
zstor secondarycache all default
zstor usedbysnapshots 0B -
zstor usedbydataset 64.2T -
zstor usedbychildren 6.30G -
zstor usedbyrefreservation 0B -
zstor logbias latency default
zstor objsetid 54 -
zstor dedup off default
zstor mlslabel none default
zstor sync standard default
zstor dnodesize legacy default
zstor refcompressratio 1.03x -
zstor written 64.2T -
zstor logicalused 65.6T -
zstor logicalreferenced 65.6T -
zstor volmode default default
zstor filesystem_limit none default
zstor snapshot_limit none default
zstor filesystem_count none default
zstor snapshot_count none default
zstor snapdev hidden default
zstor acltype off default
zstor context none default
zstor fscontext none default
zstor defcontext none default
zstor rootcontext none default
zstor relatime on local
zstor redundant_metadata all default
zstor overlay on default
zstor encryption off default
zstor keylocation none default
zstor keyformat none default
zstor pbkdf2iters 0 default
zstor special_small_blocks 0 default
zstor prefetch all default
Click to expand...

Snapshots gibt es keine
# zfs list -t snapshot
no datasets available
Click to expand...

Was mir noch aufgefallen ist, ist das ZFS meint alle inodes wären belegt. Soweit ich ich das verstanden habe erweitert zfs die inodes (dnodes) dynamisch. Korrigiert mich bitte wenn ich da falsch liege. Allerdings hätte meine Löschungen ja inodes freigeben sollen, aber das ist nicht passiert.
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
...
zstor 31099602 31099602 0 100% /mnt/datastore/zstor
Click to expand...
 
Last edited:
Deiner Ausgabe nach hast du garkein zfs dataset angelegt und direkt alles im pool zstor abgelegt, der ggf dann auch nicht mehr als 31M inodes mag:

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zstor 64.2T 0B 64.2T /mnt/datastore/zstor

hätte zB so aussehen müssen:
zstor/bspdataset1 64.2T 0B 64.2T /mnt/datastore/zstor
 
waltar said:
Deiner Ausgabe nach hast du garkein zfs dataset angelegt und direkt alles im pool zstor abgelegt, der ggf dann auch nicht mehr als 31M inodes mag:

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zstor 64.2T 0B 64.2T /mnt/datastore/zstor

hätte zB so aussehen müssen:
zstor/bspdataset1 64.2T 0B 64.2T /mnt/datastore/zstor
Click to expand...
Das ZFS wurde damals über die PBS UI erzeugt. Wir haben noch ein anderes identisches System. Dort sieht das auch so aus. Allerdings habe ich gerade mal die "df -i" Ausgaben verglichen. Das andere System hat angeblich mehr inodes.
100% volles ZFS:
zstor 31099602 31099602 0 100% /mnt/datastore/zstor
Click to expand...
identisches ZFS ca 50% auslastung:
zstor 82611840320 16760870 82595079450 1% /mnt/datastore/zstor
Click to expand...


news said:
Wie sieht genau der Pool aus? lsblk, zpool status und zpool list -v
Läuft auch regelmäßig zpool trim <pool>
Und wie sieht es mit Snapshots aus?
Nicht dass da noch welche da sind.
zfs list -r -t snapshot <pool>

Eine schöne Ausgabe erhält man mit checkzfs --sourceonly

# https://github.com/bashclub/check-zfs-replication
Click to expand...

zpool trim geht nicht weil die drehenden Platten das nicht mitmachen. Snapshots gibt es keine
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 10.9T 0 disk
├─sda1 8:1 0 10.9T 0 part
└─sda9 8:9 0 8M 0 part
sdb 8:16 0 10.9T 0 disk
├─sdb1 8:17 0 10.9T 0 part
└─sdb9 8:25 0 8M 0 part
sdc 8:32 0 10.9T 0 disk
├─sdc1 8:33 0 10.9T 0 part
└─sdc9 8:41 0 8M 0 part
sdd 8:48 0 10.9T 0 disk
├─sdd1 8:49 0 10.9T 0 part
└─sdd9 8:57 0 8M 0 part
sde 8:64 0 10.9T 0 disk
├─sde1 8:65 0 10.9T 0 part
└─sde9 8:73 0 8M 0 part
sdf 8:80 0 10.9T 0 disk
├─sdf1 8:81 0 10.9T 0 part
└─sdf9 8:89 0 8M 0 part
sdg 8:96 0 10.9T 0 disk
├─sdg1 8:97 0 10.9T 0 part
└─sdg9 8:105 0 8M 0 part
Click to expand...

# zpool trim zstor
cannot trim: no devices in pool support trim operations


# zfs list -r -t snapshot zstor
no datasets available

# python3 checkzfs.py --sourceonly
status ║ Quelle ║ Replikat ║ Snapshotname ║ Alter ║ Anzahl
════════╬════════╬══════════╬══════════════╬═══════╬═══════
ignored ║ zstor ║ ║ ║ ║ 0
Click to expand...

# zpool status -v
pool: zstor
state: ONLINE
status: Some supported and requested features are not enabled on the pool.
The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(7) for details.
scan: scrub repaired 0B in 3 days 04:54:51 with 0 errors on Wed Oct 16 05:19:20 2024
config:

NAME STATE READ WRITE CKSUM
zstor ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
wwn-0x5000c500e6cf7037 ONLINE 0 0 0
wwn-0x5000c500e6cf21be ONLINE 0 0 0
wwn-0x5000c500e6cf51a0 ONLINE 0 0 0
wwn-0x5000c500e6cf1803 ONLINE 0 0 0
wwn-0x5000c500e6cec08d ONLINE 0 0 0
wwn-0x5000c500e6ce51fa ONLINE 0 0 0
wwn-0x5000c500e6cf1873 ONLINE 0 0 0

errors: No known data errors
Click to expand...
 
Last edited:
Ich stelle auch gerade fest, dass ich diesen Thread im falschen Forum eröffnet habe.. Sorry.. :oops:
Wenn ein Mod so freundlich wäre den zu verschieben
 
Danke,

jetzt sehe ich auch eine ZFS RaidZ1 über 7 Platten.

Ich hätte das eher als ZFS RaidZ1-0 4x HDD - RaidZ1-1 4x HDD mit ZFS Special Device Mirror 2x - 3x SSD 256 GB (Partition-0) und 2x- 3x SSD 32 GB (Partition-1) SIL/ZLOG.

Ok dann bleibt nur die Daten auf ein größere PBS ZFS Pool zu übertragen, dass kann man 1:1 auch über das Netzwerk machen, wenn man 10 GBit/s zur Verfügung hat.
Ist das machbar?

Eine Erweiterung des jetzigen ZFS Pool ist auch denk, bedingt dann aber auch einen weiteres VDEV mit ZFS RaidZ1-1 7x HDD mit der selben Plattenanzahl.

Ein Datenbestand über 64.2T ist auch eine Hausnummer !
 
Last edited:
  • Like
Reactions: Johannes S
Du bist auch an die zfs default Allokierungsgrenze gelaufen (meine 2 o. 3%), deswegen auch Ausgabe inodes 100% voll (was natürlich theo. nie ereicht werden kann, sondern ist immer die Device bzw. pool Grenze.
Du bekommst beim löschen wohl keine inodes frei, weil du in einem cow FS dazu wieder "neu schreibst" (min. zB Dir Zeitstempel), was aber derzeit nicht geht. Du mußt sozusagen zum Löschen erstmal den zfs kernel Parameter (noch) kleiner machen ...
Wer hat das gerade in der Hand wie der heißt ?
 
  • Like
Reactions: j_k and Johannes S
mir fällt ein zfs set atime=off <pool> nur in dieser Situation. Der PBS braucht den Parameter sonst noch.
 
  • Like
Reactions: j_k
news said:
@waltar Siehst Du noch eine weitere Möglichkeit, den Pool und die VDEVs zu erweitern?
Click to expand...
Tja, mit 7x hdd gleichzeitig, ansonsten besser neuen pool (mirror o. min. kleinere vdevs) daneben, Daten umziehen, zuletzt alte hdd's in neuen pool mit integrieren.
 
  • Like
Reactions: j_k and Johannes S
@waltar ein ganz verrückter Gedanke:
a) Einleitung da man aus jeder Datei (ZFS Volume) auch einen ZFS Pool mit beliebiger virtueller Platten und Ausrichtung ZFS RaidX / Mirror erzeugen kann.
b) Warum nicht einfach den Speicher um 128 GB erweitern und 7x /dev/loopN; N E {0,..,6} an legen und anschließend den Pool über dieses virtuelle VDEV aus RAM temporär erweitern?
Ist riskant, wenn der Strom weg ist.
c) Das hatte ich schon mit ZFS Volume mit 2x 1 GB und 2x 2 GB als ZFS Mirror-0 2x 1 GB - Mirror-1 2x 2 GB erprobt, ging.
das VDEV ZFS Mirror-0 2x 1 GB wurde anschließend auch entfernt und alles war noch da.

Meine Tests auf meinem Desktoprechner mit zram im Anhang.

# https://wiki.archlinux.org/title/Zram
# https://wiki.ubuntuusers.de/zRam/
 

Attachments

  • Like
Reactions: fireon, waltar and j_k
Vielen Dank für die hilfreichen Antworten und Links @waltar & @news !
Ich habe in der Zwischenzeit weitere Chunks verschoben und konnte nun tatsächlich ein paar hundert MB freischaufeln.
waltar said:
Du bist auch an die zfs default Allokierungsgrenze gelaufen (meine 2 o. 3%), deswegen auch Ausgabe inodes 100% voll (was natürlich theo. nie ereicht werden kann, sondern ist immer die Device bzw. pool Grenze.
Du bekommst beim löschen wohl keine inodes frei, weil du in einem cow FS dazu wieder "neu schreibst" (min. zB Dir Zeitstempel), was aber derzeit nicht geht. Du mußt sozusagen zum Löschen erstmal den zfs kernel Parameter (noch) kleiner machen ...
Wer hat das gerade in der Hand wie der heißt ?
Click to expand...
Das hier erklärt dann wohl warum ich so viele Daten löschen/verschieben musste bevor auch nur ein wenig Platz frei wurde. Danke für den Hinweis!


Die Garbage Collection läuft jetzt erstmal. Wirft jetzt warnings wegen der missing chunks aber das war zu erwarten. Mein Plan ist nachdem die GC durch gelaufen ist und hoffentlich genug Platz freigeräumt hat, die verschobenen chunks wieder zurück zu schieben und den GC nochmal drüber laufen zu lassen.

Aktuell sieht es so aus:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zstor 64.2T 4.29G 64.2T /mnt/datastore/zstor


# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
zstor 40081134 31099602 8981532 78% /mnt/datastore/zstor
Click to expand...
Ich bin zuversichtlich und werde berichten :)
 
Last edited:
  • Like
Reactions: waltar
news said:
ein ganz verrückter Gedanke:
Click to expand...
@news: Jau, interessant, fehlen im Moment noch die freie Menge von theo. 7x 128GB zram die erstmal auf nahezu nichts zusammen schrumpfen ... und bloß keinen Fehler dabei machen. Ist gut für eine "Spielwiese", aber auf einem Produktivrechner, wo der sich dann eh schon nicht wohl fühlt ist das ein sehr heißes Eisen, will ja keiner die Daten aus Versehen in's Nirwana verlieren.
 
Nein man kann einfach jeden Speichern, den man frei hat, nutzen: 7x n GB.
Im meinem Test 4x 1 GB DDR4 Ram als ZFS RaidZ1.
 
Ist mir schon klar, 7x 1GB ginge auch ..., aber hinterher "(pool) gesund" wieder ausgebaut bekommen ... - ohne ausgiebige vorherige Tests auf Spielehost würde ich da lieber die Finger von lassen, man muß dann schon wissen was und wie man was tut bzw. und was man dann nicht tuen darf :)
 
Das ist eine geheime Schubladenlösung, die man normalerweise nicht macht, aber wenn "alle Stricke reizen" ... holt man das als letztes Mittel hervor, insofern gut zu wissen und zu haben, immer in der Hoffnung ein/das Problem am Besten garnicht erst bis hierhin getrieben zu haben - gesundes Monitoring setup, natürlich mit Gegenreaktion darauf, hätte diesen (Not-)Fall verhindern können.
Immerhin jetzt klappt's ja wieder und Haufen mehr Platz oder weniger Backup muß nun her :)
 
  • Like
Reactions: news
Der GC hat lang gerödelt aber hat nun knapp 6T weggeräumt \o/ Wir werden wohl den Storage erweitern. So wie ich gelesen habe lässt sich ein raidz nicht einfach erweitern. Also wäre demnach ein weiteres raidz, und damit Datastor, der beste Weg?!
Danke nochmal für eure Hilfe!
 
You must log in or register to reply here.
Top Bottom