Belegung von Speicherplatz in ZFS-Pool

[virshling]

Guten Abend,

vermutlich ist die Frage samt Antwort schon 100 mal gepostet worden - ich finde sie trotzdem nicht ... :
Ich sehe einfach nicht, was genau meinen Speicherplatz frisst.
in einem ZFS-Pool auf Raid-Z2 befinden sich zwei Container mit je 50-60 GB und eine VM mit 350 GB.
zfs list zeigt mir für die disk der VM 868 GB unter USED an, USEDREFRESERV 515 GB.
Das heißt 515 GB entfallen auf Snapshots, richtig?
Der einzige Snapshot, den ich mit zfs list sehen kann, ist aber einer für die Replikation, in der GUI ist gar kein Snapshot vorhanden.

root@pve-3:~# zfs list -t all -o space -r hipspool
NAME                                                       AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
hipspool                                                    730G   876G        0B   41.1K             0B       876G
hipspool/subvol-680-disk-0                                 58.2G  3.11G     1.27G   1.84G             0B         0B
hipspool/subvol-680-disk-0@VorUpDate                           -   714M         -       -              -          -
hipspool/subvol-680-disk-0@vorEinrichtCups                     -   582M         -       -              -          -
hipspool/subvol-680-disk-0@__replicate_680-0_1619449501__      -  3.46M         -       -              -          -
hipspool/subvol-700-disk-0                                 53.2G  4.64G     1.87G   2.78G             0B         0B
hipspool/subvol-700-disk-0@Grundeinstellung                    -   710M         -       -              -          -
hipspool/subvol-700-disk-0@vorAenderungenWorkflow              -   364M         -       -              -          -
hipspool/subvol-700-disk-0@vorMultiAssigPlugIn                 -   378M         -       -              -          -
hipspool/subvol-700-disk-0@__replicate_700-0_1619447401__      -  3.64M         -       -              -          -
hipspool/vm-650-disk-0                                     1.22T   868G      265M    353G           515G         0B
hipspool/vm-650-disk-0@__replicate_650-0_1619442001__          -   265M         -       -              -          -
root@pve-3:~#

Jetzt möchte ich natürlich wissen, wie die 515 GB belegt werden und freue mich über einen Rat.
Vielen Dank

Bernhard

 

[0xd149e38e]

Das heißt 515 GB entfallen auf Snapshots, richtig?

Nein. Der Snapshot braucht nur 265MB.

Das liegt warscheinlich am think-provisioned zvol, oder evtl am fehlenden trim und zfs compression.
Da gab es mal einen thread dazu:
https://forum.proxmox.com/threads/how-to-reclaim-space-in-zfs-sparse-volume.34171/post-169951

 

[virshling]

Hm, danke für den Link, aber ehrlich gesagt, weiß ich noch immer nicht weiter. Kompression ist jedenfalls nicht aktiv und ThinProvisioning auch nicht.

 

[H4R0]

Vollblocksize nicht angepasst und wahrscheinlich kein discard in der vm aktiviert.

Da volblocksize falsch gesetzt ist wirst du die vdevs eh neu anlegen müssen.

Gibt nen haufen threads dazu, einfach die suche verwenden.

 

[virshling]

Danke für eure Antworten.
Die Lektüre dieses lehrreichen Threads hat mich etwas klüger gemacht, aber es bleiben Fragen offen:

Da volblocksize falsch gesetzt ist wirst du die vdevs eh neu anlegen müssen.

1. vdevs? nicht die zvols? Ich hätte erst die vblocksize verdoppelt und dann die virtuelle Platte des Gastsystems auf eine neu erstellte kopiert, wie in dem verlinkten Thread vorgeschlagen. Oder ist das in meinem Falle der falsche Ansatz?
   
   
2. Die Funktion Discard finde ich nur im Zusammenhang mit ThinProvisioning, Trim nur bei SSDs, während sich bei mir alte SAS-Platten drehen.Oder habe ich etwas übersehen?

Es laufen fünf alte SAS Platten in einem Raid Z2.
Plattengröße jeweils 640 GB
Blocks haben 512B

volblocksize = 8K
ashift = 9

Laut Tabelle liegt mein Raid-Z-Parity-Cost also bei 47% (Zelle C19)
Das erklärt tatsächlich die 515 GB, denen ich so nachtrauere.
Allerdings scheint es keinen Weg zu geben, durch Änderung der Blockgröße oder sonstwie, mehr als 20GB zu gewinnen.
OS aller Gastsysteme ist übrigens Linux, die große VM ist ein Fileserver.
Unterm Strich scheint mir der erwartbare Gewinn an Platz oder Perfomance nach Änderungen an volblocksize oder ashift also recht gering.
Erneut die Frage: hab ich etwas wesentliches übersehen?
Danke schon mal!

 

[H4R0]

Die Funktion Discard finde ich nur im Zusammenhang mit ThinProvisioning, Trim nur bei SSDs, während sich bei mir alte SAS-Platten drehen.Oder habe ich etwas übersehen?

Es geht um discard in der VM, wenn du Dateien in der VM löschst, werden diese nicht an den Hypervisor weitergegeben und belegen weiterhin Speicher. Die Festplatte wächst entsprechend langsam auf das maximum an.

Laut Tabelle liegt mein Raid-Z-Parity-Cost also bei 47% (Zelle C19)
Das erklärt tatsächlich die 515 GB, denen ich so nachtrauere.
Allerdings scheint es keinen Weg zu geben, durch Änderung der Blockgröße oder sonstwie, mehr als 20GB zu gewinnen.

Mit 256kb block size bist du bei 40%, dass sind 224gb unterschied. Raidz2 ist bei 5 platten halt sehr ungünstig.

Bei 640GB platten hätte ich auch eher Raidz1 genutzt, der resilver ist sowieso im nu durch.

Wenn du das raidz2 als raid1 neu baust hast du brutto 864gb mehr.

Ein raid ersetzt kein backup.

 

[Dunuin]

Mit 256kb block size bist du bei 40%, dass sind 224gb unterschied. Raidz2 ist bei 5 platten halt sehr ungünstig.

256 bezieht sich in der Tabelle auf Sektoren. Die 40% wäre dann sogar schon bei "nur" 128K volblocksize. Aber ja...128K Volblocksize würde ich auch nicht haben wollen wenn da vielleicht noch DBs oder ähnliches in VMs laufen sollten.

Bei 640GB platten hätte ich auch eher Raidz1 genutzt, der resilver ist sowieso im nu durch.

Wenn du das raidz2 als raid1 neu baust hast du brutto 864gb mehr.

Ein raid ersetzt kein backup.

Oder wenn man die als VM Storage nutzt und mehr Performance will halt ein Stripped Mirror draus machen. Die 50% vs 47% Kapazitätsverlust machen den Kohl dann auch nicht mehr fett. Aber auch hier sind dann 5 Platten eine ungünstige Zahl, falls einem 4 Platte nicht reichen (die 5te hätte man ja als Spare nehmen können).

 

[virshling]

Herzlichen Dank für die erhellenden Antworten und Entschuldigung für die späte Reaktion, ich bin diese Woche noch nicht dazu gekommen, das Thema weiter zu verfolgen.

Es geht um discard in der VM, wenn du Dateien in der VM löschst, werden diese nicht an den Hypervisor weitergegeben und belegen weiterhin Speicher. Die Festplatte wächst entsprechend langsam auf das maximum an.

Danke, das war mir tatsächlich nicht bewusst. Soweit ich das verstehe, muss ich dafür auf dem pve-Node mit virsh edit <VM> die Kofiguration der VM editieren und de Eintrag discard='unmap' machen. Stimmt das soweit (hab ich noch nie gemacht)?

Die 50% vs 47% Kapazitätsverlust machen den Kohl dann auch nicht mehr fett.

Ja, zu diesem Schluss bin ich ja auch gekommen. Es läuft wohl darauf hinaus, den Pool bei Gelegenheit neu zu erstellen und dann als Raid10 mit sechs Platten - drei Mirrors und und je zwei Stripes, dann ist die Ausfallsicherheit wieder auf dem gleichen Stand wie bei RaidZ2.
Aber erst einmal muss ich einen zweiten Node auf bessere Hardware umziehen und auch dazu hätte ich eine Frage, die mit dem bisherigen Thread zusammenhängt:
Auf diesem anderen Node gibt es einen ZFS-Pool gleichen Namens (dort als Raid1), auf den ich die besagte VM und die Container repliziere.
Wie gesagt, funktioniert das bisher ohne Kompression oder ThinProvisioning/sparse.
Bekomme ich denn neue interessante Probleme, wenn ich die VM aus dem RaidZ2-Pool auf einen weiteren Node repliziere, auf dem ich aber Kompression und sparse aktivieren möchte? Oder anders formuliert: müssen diese beiden Funktionen auf beiden Nodes identisch eingestellt sein, damit die Replikation reibungslos verläuft?