ZFS Speicher Information

[DerT]

Hi Leute,

ich bin gerade meine Speicherkonfiguration durchgegangen und dabei kam mir eine Frage auf.
Wir kann ich mir die Netto und Brutto Kapazität meines ZFS Speichers anschauen?

ZFS Version:
zfs-0.8.4-pve2
zfs-kmod-0.8.4-pve1

Ich habe folgendes Setup.

3 Festplatten à 1,8TB als RAIDZ1 konfiguriert.
1 SSD als Cache.



Nun würde ich erwarten, dass sich daraus 5,4 TB Brutto und 3,6 TB Netto ergeben.

Was sich auch beim Befehl "zpool list" widerspiegelt.





Beim Befehl "zfs list" kommt aber folgendes raus.



Hier steht nun das "zfs_storage" 2,01 TB verfügbar hat.
Mir ist klar, dass bei "zpoo list" der Brutto Speicher angezeigt wird.
Ich hätte aber erwartet, dass bei "zfs list" dann der Netto Speicher stehen würde.

Kann mir jemand erklären woran das liegt?

Danke und Gruß
T

 

[Dunuin]

Sieht doch ok aus. 1.5T USED + 2.01T AVAIL = 3.5T Nettokapazität. Das passt doch dann ziemlich gut zu deinen errechneten 3.6T. Ein bisschen was verlierst du ja immer wegen Overhead. Interessanter wäre die Frage, ob du deine Volblocksize angepasst hattest. Falls du ashift=12 verwendet hast und es bei der Default Volblocksize von 8K belassen hast, dann hast du in echt nur 2,7TB nutzbare Kapazität, da alle zvols 50% mehr Platz als nötig verbrauchen wegen schlechtem Padding. Musst du im Gast 120 mal gucken wie voll laut dem die virtuelle Festplatte ist. Wenn du die Volblocksize nicht angepasst hast, dann würde ich vermuten, dass da der Gast nur so ca 191GB nutzt aber die Zvol auf dem Pool 290GB verbaucht.

 

[H4R0]

Hast du die block size auf 64kb gesetzt, statt 8kb ? Ansonsten hast du bei raidz eine menge overhead.

https://forum.proxmox.com/threads/virtual-disks-stealing-more-space-than-allocated-help.78349

 

[DerT]

Sieht doch ok aus. 1.5T USED + 2.01T AVAIL = 3.5T Nettokapazität. Das passt doch dann ziemlich gut zu deinen errechneten 3.6T. Ein bisschen was verlierst du ja immer wegen Overhead. Interessanter wäre die Frage, ob du deine Volblocksize angepasst hattest. Falls du ashift=12 verwendet hast und es bei der Default Volblocksize von 8K belassen hast, dann hast du in echt nur 2,7TB nutzbare Kapazität, da alle zvols 50% mehr Platz als nötig verbrauchen wegen schlechtem Padding. Musst du im Gast 120 mal gucken wie voll laut dem die virtuelle Festplatte ist. Wenn du die Volblocksize nicht angepasst hast, dann würde ich vermuten, dass da der Gast nur so ca 191GB nutzt aber die Zvol auf dem Pool 290GB verbaucht.

Hi danke für die Antwort.
Hatte irgendwie die Zahlen falsch interpretiert und vergessen USED und AVAIL zusammen zu zählen.

Aber um mal auf "ashift" und "Block Size" zu sprechen zu kommen.
Ja du hast recht der Gast 120 hat eigentlich eine 130 GB Platte (welche voll ist).
Das hab ich nicht mal bemerkt, dass der 290GB frisst.

Ja ich habe scheinbar ashift 12 beim erstellen angegeben.


Und die Blocksize ist bei 8K


Nun würde ich das gerne anpassen um nicht so viel Speicher zu verschwenden.
Welche Werte würdet ihr empfehlen?

Im verlinkten Beitrag von @H4RO wird auch darüber gesprochen es zu ändern.
https://forum.proxmox.com/threads/virtual-disks-stealing-more-space-than-allocated-help.78349/

Dort steht.
Set Datacenter -> Storage -> RaidZ1 Pool -> Block Size: 64kb and recreate your vm disk

Leider weiß ich gerade nicht wie ich die disk "neu erstelle".
Beim googeln bin ich auch auf nichts gestoßen.
Etwa ein Backup erstellen und wiederherstellen?

Bin zwar beruflich Sys-Admin aber in Sachen Proxmox und ZFS noch blutiger Anfänger.
Gibt es noch andere "Tipps und Tricks" die man beachten sollte?
Gerne auch als Thema zum einlesen.

Danke und Gruß
T

 

[Dunuin]

Das Problem ist, dass die Volblocksize nur beim Erstellen einer virtuellen Festplatte (zvol) setzbar ist und später nicht mehr verändert werden kann. Musst du dann entweder alle VMs komlett neu aufsetzen oder der VM eine zweite virtuelle Festplatte hinzufügen (nachdem du beim Pool die Volblocksize geändert hast). Die neue zvol wäre dann mit der neuen Volblocksize erstellt. Und dann musst du irgendwie all deine Daten von der alten auf die neue Festplatte kopieren und später die alte zvol entfernen und zerstören. Das würde z.B. mit einem "zfs send | zfs recieve"-Konstrukt klappen oder mit dem dd-Befehl, was dann eine 1-zu-1-Kopie auf Blockebene macht.
Oder du versuchst das ganze auf Dateiebene, was aber ziemlich kompliziert ist, da sich die UUIDs ändern und auch der grub und das initramfs für die neuen UUIDs neu gebaut werden muss. Das hatte ich mal hier dokumentiert, als ich auch die Volblocksize für meine Debian-VM ändern musste.

Ist generell ein ziemlicher Krampf das Ganze.

Guck mal hier wegen der Volblocksize. Da würde sich bei dir mit 3 Laufwerken mit ashift=12 im raidz1 z.B. eine Volblocksize von 16K anbieten. Bei 4K und 8K solltest du nur 50% der Gesamtkapazität nutzen können und bei 16K, 32K, 64K und 128K jeweils die optimalen 66%. Und da dann am besten den kleinstmöglichen Wert nehmen, dass das mit dem Padding von der VM zum Host besser passt...also 16K.
Außer du weißt jetzt schon, dass du da später einmal einen größeren Pool nutzen willst. Wenn du z.B. den raidz1 Pool mit 3 Laufwerken später zerstören willst, um daraus einen größeren raidz1 Pool mit 5 Laufwerken zu erstellen, dann würde ich gleich die Volblocksize von 32K wählen. Weil du sonst später das gleiche Problem hast wie jetzt und wieder alle VMs anpassen müsstest.

 

[DerT]

Das Problem ist, dass die Volblocksize nur beim Erstellen einer virtuellen Festplatte (zvol) setzbar ist und später nicht mehr verändert werden kann. Musst du dann entweder alle VMs komlett neu aufsetzen oder der VM eine zweite virtuelle Festplatte hinzufügen (nachdem du beim Pool die Volblocksize geändert hast). Die neue zvol wäre dann mit der neuen Volblocksize erstellt. Und dann musst du irgendwie all deine Daten von der alten auf die neue Festplatte kopieren und später die alte zvol entfernen und zerstören. Das würde z.B. mit einem "zfs send | zfs recieve"-Konstrukt klappen oder mit dem dd-Befehl, was dann eine 1-zu-1-Kopie auf Blockebene macht.
Oder du versuchst das ganze auf Dateiebene, was aber ziemlich kompliziert ist, da sich die UUIDs ändern und auch der grub und das initramfs für die neuen UUIDs neu gebaut werden muss. Das hatte ich mal hier dokumentiert, als ich auch die Volblocksize für meine Debian-VM ändern musste.

Ist generell ein ziemlicher Krampf das Ganze.

Guck mal hier wegen der Volblocksize. Da würde sich bei dir mit 3 Laufwerken mit ashift=12 im raidz1 z.B. eine Volblocksize von 16K anbieten. Bei 4K und 8K solltest du nur 50% der Gesamtkapazität nutzen können und bei 16K, 32K, 64K und 128K jeweils die optimalen 66%. Und da dann am besten den kleinstmöglichen Wert nehmen, dass das mit dem Padding von der VM zum Host besser passt...also 16K.
Außer du weißt jetzt schon, dass du da später einmal einen größeren Pool nutzen willst. Wenn du z.B. den raidz1 Pool mit 3 Laufwerken später zerstören willst, um daraus einen größeren raidz1 Pool mit 5 Laufwerken zu erstellen, dann würde ich gleich die Volblocksize von 32K wählen. Weil du sonst später das gleiche Problem hast wie jetzt und wieder alle VMs anpassen müsstest.

Danke für die extrem ausführliche Antwort.
Prinzipiell ist das System darauf ausgelegt Server für private Zwecke zu hosten. (Hausautomatisierung, Nextcloud, dhcp, DNS usw..)
Mit Ausnahme der Nextcloud also nicht für große Mengen Daten.
Ich gehe aktuell davon aus das ich alle 2-3 Jahre eine weitere Platte mit 2TB einbauen muss oder Daten löschen muss.
Würde aufgrund dessen aber trotzdem zu den 32K tendieren.
ich werde die Tage mal versuchen eine Festplatte zu kopieren.
Ist die Änderung direkt aktiv wenn ich die Block Size in der GUI anpasse?

Zusätzlich habe ich noch einen weitere Frage.
Das RAIDz aus HDDs ist für Daten und große Festplatten gedacht.
Die Platten der meisten Server liegen auf einer SSD die in keinem RAID läuft.
Der Hypervisor an sich liegt auf einer weiteren SSD die auch in keinem RAID läuft.
Gibt es hier auch noch ein paar Kniffe die man wissen sollte um das ganze zu optimieren?

Danke und Gruß
T

 

[Dunuin]

Ich gehe aktuell davon aus das ich alle 2-3 Jahre eine weitere Platte mit 2TB einbauen muss oder Daten löschen muss.

Denk daran, dass ich ZFS Pool nicht erweitern lassen. Einfach eine weitere Platte hinzufügen geht da leider nicht. Musst du dann die Daten auf dem Pool extern sichern, Pool zerstören, einen neuen Pool mit mehr Festplatten erstellen und dann alles wieder auf den neuen Pool kopieren.

Ist die Änderung direkt aktiv wenn ich die Block Size in der GUI anpasse?

Ja, wird meines Wissens sofort übernommen. Aber gibt halt nur für neu erstellte virtuelle Festplatten und nicht für deine alten.

Die Platten der meisten Server liegen auf einer SSD die in keinem RAID läuft.
Der Hypervisor an sich liegt auf einer weiteren SSD die auch in keinem RAID läuft.
Gibt es hier auch noch ein paar Kniffe die man wissen sollte um das ganze zu optimieren?

Laufen die einzelnen SSDs dann als ZFS oder LVM?

 

[DerT]

Denk daran, dass ich ZFS Pool nicht erweitern lassen. Einfach eine weitere Platte hinzufügen geht da leider nicht. Musst du dann die Daten auf dem Pool extern sichern, Pool zerstören, einen neuen Pool mit mehr Festplatten erstellen und dann alles wieder auf den neuen Pool kopieren.

Die Info war mir auch neu. Aber damit kann ich leben. Jetzt ist der Pool mit drei Platten eh schon aktiv. Beim ersten erweitern werde ich dann wohl direkt auf 5 gehen.

Laufen die einzelnen SSDs dann als ZFS oder LVM?

LVM-Thin

Aktuell schaut meine Speicher Konfiguration wie folgt aus.


Auf dem ZFS Speicher liegen zwei Backup Ordner die aber eher selten genutzt werden.
Zusätzlich noch der Speicher der ISO-Images und der Festplatten die viel Speicher benötigen (HDD-DIsks).

loval-lvm ist auf der System SSD und aktuell nicht genutzt. Außer für das System halt.
ssd_lvm ist die Zweite SSD welche nur für Festplatten bzw. Container gedacht ist.


Noch eine weitere Frage,

betrifft das auch die Festplatten meiner Container?
Beispielsweise :
"zfs_storage/vmstorage/subvol-108-disk-0 44.2G 156G 44.2G /zfs_storage/vmstorage/subvol-108-disk-0"

Also sollte ich die auch mit zfs send *** | zfs reciv *** kopieren?

Außerdem wünsch ich euch eine besinnliche Weihnachtszeit

Gruß
T

 

[Dunuin]

Nein, volblocksize gilt nur für zvols, also die virtuellen Festplatten der VMs.
Bei LXCs werden Datasets genutzt, die haben keine volblocksize sondern sondern eine recordsize. Die scheint aber standardmäßig auf 128K zu sein, also hoch genug, dass da ein raidz keinen Platz durch Padding verschwendet.

 

[DerT]

@Dunuin
Vielen Dank.
Ich habe nun alle Festplatten neu erstellt.
Wie erwartet hat sich der Speicherbedarf reduziert.



Allerdings ist mir dabei etwas komisches aufgefallen.
1. VN101 belegt über "zfs list" weniger Speicher als mir im Gast mit "df -h" angezeigt wird.

ID	Vor neu erstellen	Nach neu erstellen	Laut gast
VM101	10,3G	501M	644M

Warum ist die Festplatte in ZFS LIST nur 501M groß?


2. Es gibt Gäste bei denen der Bedarf leicht größer wurde.

ID	Vor neu erstellen	Nach neu erstellen	Laut gast
VM106	105G	106G	75G

Wenn ich Abseits des ZFS Themas noch andere Fragen habe ist es wohl schlauer ein neues Thema zu eröffnen oder?

Ps.
Für alle die eine Festplatte neu erzeugen müssen.
Das ganze geht sehr einfach mit dem folgenden Ablauf.

1. Festplatte kopieren mit "zfs send | zfs recv"
Beispiel:
zfs send zfs_storage/vmstorage/base-105-disk-0 | zfs recv zfs_storage/vmstorage/base-105-disk-1

2. Konfigurationsdatei der VM unter "/etc/pve/qemu-server" anpassen.
- Dort muss der Name der verbundenen Festplatte angepasst werden und die alte als "unused" hinzugefügt werden.
- Danach kann die alte Festplatte über die GUI einfach gelöscht werden.

 

[Dunuin]

@Dunuin
Vielen Dank.
Ich habe nun alle Festplatten neu erstellt.
Wie erwartet hat sich der Speicherbedarf reduziert.

View attachment 22285

Allerdings ist mir dabei etwas komisches aufgefallen.
1. VN101 belegt über "zfs list" weniger Speicher als mir im Gast mit "df -h" angezeigt wird.

ID	Vor neu erstellen	Nach neu erstellen	Laut gast
VM101	10,3G	501M	644M

Warum ist die Festplatte in ZFS LIST nur 501M groß?
View attachment 22290

Das die virtuelle HDD auf dem Pool weniger Platz benötigt als was in dem Gast angezeigt wird kann durchaus richtig sein. Wenn du nichts umgestellt hast, dann nutzt ZFS standardmäßig die LZ4-Kompression. Gerade wenn du sehr viele gut komprimierbare Daten hast, dann lässt sich da durchaus ein Großteil sparen. Du kannst mal zfs get compressratio eingeben. Dann siehst du wie gut sich so ein zvol oder Dataset komprimieren ließ. 1.00x = Größe unverändert, 2.00x = Daten belegen nur noch 50% der Ursprungsgröße, 3.00x = nur noch 1/3 der Ursprungsgröße etc.
Vom Gast mit 644M zu 501M auf dem Pool wäre also nichts ungewöhnliches. Dass das vorher 10,3G und jetzt nur noch 501M ist macht mich aber schon stutzig. Entweder hattest du da früher kein funktionierendes Discard eingerichtet und es würde daher sehr viel Platz unnötig verschwendet, oder da ist etwas beim "zfs send | zfs receive" schief gelaufen. Wenn du die alte virtuelle HDD noch nicht gelöscht hast, dann vergleich doch mal am besten dessen Inhalt, ob da wirklich alles stimmt.

2. Es gibt Gäste bei denen der Bedarf leicht größer wurde.

ID	Vor neu erstellen	Nach neu erstellen	Laut gast
VM106	105G	106G	75G

Wenn ich Abseits des ZFS Themas noch andere Fragen habe ist es wohl schlauer ein neues Thema zu eröffnen oder?

Wenn das ein Linux ist kannst du mal im Gast ein fstrim -a ausführen und so ein manuelles discard für alle Dateisysteme ausführen. Am besten vorher noch einmal checken, ob da in der Proxmox GUI für die VM beim SCSI Controller die "Discard" Checkbox auch wirklich gesetzt ist. Nimmt die zvol dann auf dem Pool weniger Platz weg, dann hattest du ein Problem mit dem Discard/Trim und du solltest entweder automatisches Discard aktivieren, indem du im Gast unter /etc/fstab zu den Mount-Optionen noch ein ",discard" dranhängst oder du könntest auch täglich/wöchentlich per cron "fstrim -a" laufen lassen.

Eine Besonderheit von ZFS, die mich auch am Anfang verwirrt hat, ist dass da ZFS nicht augenblicklich Daten löscht. Wenn du z.B. 1TB vom Pool löscht, dann kann das viele Minuten dauern, bis wirklich alles gelöscht ist. Dem Pool also nach größeren Löschaktionen immer etwas Zeit geben sich zu leeren. Da kann man regelrecht zugucken, wie da nach und nach GB um GB freigemacht werden.

 

[DerT]

Hi,

noch einmal vielen Dank für deine sehr ausführlichen Erklärungen.

Das mit der Kompression wusste ich auch noch nicht, wirkt aber logisch.
V101 hat eine Kompression von 1,58. Also plausibel.
Hab mal eine neue VM mit der alten Festplatte vom Gast 101 erstellt, die hat dann laut ZFS LIST 10,1G und laut Gast 644M.
Es funktioniert auch alles, also ist beim neu erstellen nichts verloren gegangen.

Verstehe ich das richtig, dass ich am besten immer die Option "Discard" aktiviert haben sollte?
Auch bei der root Partition?
Aktuell ist der Haken bei Discard nirgends gesetzt.
Sollte ich zusätzlich, zu dem Haken, die Discard Option in der /etc/fstab eintragen?

Wie verhält es sich bei einem Windows Gast?
Sollte hier auch "Discard" aktiviert werden.

Vielen Dank für den Tipp mit dem Speicherplatz beim löschen.

Ich konnte durch die ganzen Anpassungen nun 500G einsparen.
Was wirklich ne Menge ist.

 

[Dunuin]

Verstehe ich das richtig, dass ich am besten immer die Option "Discard" aktiviert haben sollte?
Auch bei der root Partition?
Aktuell ist der Haken bei Discard nirgends gesetzt.
Sollte ich zusätzlich, zu dem Haken, die Discard Option in der /etc/fstab eintragen?

Wie verhält es sich bei einem Windows Gast?
Sollte hier auch "Discard" aktiviert werden.

ZFS nutzt normal Thin-Provisioning, da muss man immer dafür sorgen, dass Discard genutzt wird. Das gleiche wenn man SSDs benutzt. Setzt das Betriebssystem keine TRIM-Befehle ab, dann weiß ZFS oder eine normale SSD nicht, das etwas gelöschtes auch wirklich gelöscht sein sollte.
Windows sollte eigentlich automatisch TRIM benutzen. Bei Linux muss man meist selbst dafür sorgen und das erst einrichten.

Es gibt ein paar Ausnahmen wo man eventuell kein Trim nutzen möchte. Z.B. wenn man eine verschlüsselte Partition hat, wo es die Sicherheit schwächen würde. Oder auch beim SWAP, wo es dafür sorgen kann, dass da einmalig dann immer der ganze SWAP-Partition beim Boot komplett neugeschrieben wird, was dann auf die SSD-Lebenszeit geht.
Ansonsten sollte aber immer Trim/Discard aktiviert sein.

Wie man das mit dem Trim/Discard genau löst ist Geschmackssache. Manche lassen das einfach bei jeder kleinen Löschoperation ausführen, was dann passiert, wenn man die "discard"-Option in der "/etc/fstab" setzt. Das kann aber auf die Leistung gehen, da dann eben TRIM-Befehle ständig mitausgeführt werden. Stattdessen kann man z.B. auch dafür sorgen, dass da regelmäßig ein manuelles "fstrim -a" ausgeführt wird.
Ich habe dafür in jeder Linux-VM dieses Script hier angelegt und lasses das per Cron einmal am Tag als root ausführen:

#!/bin/sh
#
# To find which FS support trim, we check that DISC-MAX (discard max bytes)
# is great than zero. Check discard_max_bytes documentation at
# https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt
#
# Copy script to /etc/cron.daily or /etc/cron.weekly
#
for fs in $(lsblk -o MOUNTPOINT,DISC-MAX,FSTYPE | grep -E '^/.* [1-9]+.* ' | awk '{print $1}'); do
    fstrim "$fs"
done