ZFS und verwirrende Angaben bzgl der Größe

[whiterabbit]

Hallo.
Diese Frage läuft sicher nicht zum ersten Mal ... aber ich möchte sie trotzdem nochmal stellen, da ich die Größenangaben bei Verwendung von ZFS-Pools weiterhin verwirrend finde.

Die Situtation ist: IBM-M4-Server mit 4 Platten zu einem Z2-Pool (mit Cache). Unter Disks -> ZFS sehe ich dies:


Also verfügbar (ohne Deduplizierung): 3.41 TB.
Wenn ich aber unter Storage -> Übersicht auf den ZFS-Pool schaue, sehe ich:


Dort steht nun also 3.35 TB.

Wenn ich auf die VM selbst gehe, sehe ich: Disk-Size 2.55 TB


Nun würde ich erwarten, dass das ~ 2.55/3.35 = 76% entspricht. Aber die Auslastung zeigt mir ~92% an.
Zudem warnt mich checkMK mit dieser Anzeige, wo wieder etwas anderes steht:

Ich finde das äußerst verwirrend. Welche Angabe denn nun "richtig"??

Hintergrund der Frage: Ich hatte die Partition für diese VM mit Proxmox-Bordmitteln vergrößert, da der Plattenplatz knapp geworden ist. Da ZFS bei mehr als 80% Belegung scheinbar langsam wird, wollte ich natürlich tunlichst unterhalb der 80% Grenze bleiben. Doch jetzt ist genau das Gegenteil geschehen, weil ich die Größe des Dateisystems offenbar falsch gedeutet habe.

Danke für Klärung!

 

[mr44er]

Unter Disks -> ZFS sehe ich dies:

zpool list -> das ist die Bruttokapazität aller disks.

Wenn ich aber unter Storage -> Übersicht auf den ZFS-Pool schaue, sehe ich:

zfs list -> Das ist die Nettokapazität "was nach Redundanz übrig bleibt"
7,15/4 = 1,7875 -> 1,7875*2 = 3,575 (Abweichungen wegen TB/TiB)
Das müsste man jetzt noch vom brutto abziehen, aber da du raidz2 bei 4 disks hast, kommst du aufs Gleiche raus.

Da ZFS bei mehr als 80% Belegung scheinbar langsam wird, wollte ich natürlich tunlichst unterhalb der 80% Grenze bleiben.

Korrekt. Aber das Gefühl, dass ein Anker geworfen wurde, kommt erst bei weit über 90%.
Schlimm ist das nicht, achte nur darauf, dass du den pool nicht komplett vollmachst. Das kann dann zu Problemen führen, wenn du nichts mehr löschen kannst.

 

[IsThisThingOn]

RAIDZ ist für ZVOL (also VM disks) nicht geeignet.
Du hast die gleiche Kapazität wie zwei mirrors.
Aber halt alle Nachteile von RAIDZ.

Z2-Pool (mit Cache)

Was für ein "cache"?

Also verfügbar (ohne Deduplizierung): 3.41 TB.

Du hast aber nicht deduplication aktiv?!

Nun würde ich erwarten, dass das ~ 2.55/3.35 = 76% entspricht. Aber die Auslastung zeigt mir ~92% an.

Ist bisschen fies von ZFS, aber diese Erwartung ist falsch!
Das eine ist die Grösse der VM disk in einem ZVOL. Das zweite ist die Auslastung des pools.
Ich kann eine 1TB VM disk haben, die aber wegen einer falschen pool Geometry und/oder wegen padding mehr als 1TB tatsächlichem Speicher auf dem pool verbraucht.

Nehmen wir mal an, ich habe ein RAIDZ2 mit 4 Festplatten.
So würde sich dies in RAIDZ verhalten:

With 4 drives, we get a stripe 4 drives wide.
Each stripe has two 4k data sectors and two 4k parity sectors.
For a volblock of 16k, we need two stripe (16k/8k = 2).
That gets us to 32k in total to store 16k.
32k is 8 sectors and that can't be divided by 3 so there is padding needed.
We need another padding sector to get to 9 sectors total.
9 sectors can be divided by 3.
That gets us to 36k in total to store 16k.
We expected a storage efficiency of 50%, but only got 44.44%!
That is WORSE than mirror!

Quelle: https://github.com/jameskimmel/opinions_about_tech_stuff/blob/main/ZFS/The problem with RAIDZ.md#raidz2-with-4-drives

Um 1TB VM disk zu Speichern, brauche ich also 1.13 TB an Speicher auf dem pool.

Oder um es mit deine Zahlen zu rechnen:

2.55 / 44 * 100 = 5.795 TB
5.795TB / 100 * 50 = 2.898 TB

Mindestens 2.89TB sind nötig um deine 2.55TB disk auf dem pool zu speichern.

TLDR: Benutzte für Proxmox mirror! Niemals RAIDZ.
RAIDZ eignet sich nur für datasets, nicht für ZVOLs. Und selbst bei datasets muss man aufpassen mit RAIDZ.

 

[Johannes S]

TLDR: Benutzte für Proxmox mirror! Niemals RAIDZ.
RAIDZ eignet sich nur für datasets, nicht für ZVOLs. Und selbst bei datasets muss man aufpassen mit RAIDZ.

Siehe auch:

[TUTORIAL] Thread 'FabU: Can I use ZFS RaidZ for my VMs?'

Jan 1, 2025

Assumption: you use at least four identical devices for that. Mirrors, RaidZ, RaidZ2 are possible - theoretically.

Technically correct answer: yes, it works. But the right answers is: no, do not do that! The recommendation is very clear: use “striped mirrors”. This results in something similar to a classic Raid10.

(1) RaidZ1 (and Z2 too) gives you the IOPS of a single device, completely independent of the actual number of physical devices. For the “four devices, mirrored” approach this will double --> giving twice as many Operations per Second. For a large-file...

• UdoB
• mirrors raidz vm storage zfs
• Replies: 3
• Forum: Proxmox VE: Installation and configuration

• 

 

[IsThisThingOn]

Siehe auch:

[TUTORIAL] Thread 'FabU: Can I use ZFS RaidZ for my VMs?'

Jan 1, 2025

Assumption: you use at least four identical devices for that. Mirrors, RaidZ, RaidZ2 are possible - theoretically.

Technically correct answer: yes, it works. But the right answers is: no, do not do that! The recommendation is very clear: use “striped mirrors”. This results in something similar to a classic Raid10.

(1) RaidZ1 (and Z2 too) gives you the IOPS of a single device, completely independent of the actual number of physical devices. For the “four devices, mirrored” approach this will double --> giving twice as many Operations per Second. For a large-file...

• UdoB
• mirrors raidz vm storage zfs
• Replies: 3
• Forum: Proxmox VE: Installation and configuration

• 

Super thread!

Ich finde Proxmox sollte in der Doku warnen for RAIDZ und mirror empfehlen.

 

[mr44er]

Naja, es ist kein Totalschaden oder Beinbruch mit Stichflamme. Nur eben so gar nicht optimal, erst recht nicht mit nur 4 disks.
Man lernt ja was bei!

 

[whiterabbit]

Danke für die ganzen Infos .
Ich werde den ZFS-Pool auflösen und zu einem Mirror machen. Das geht hoffentlich innerhalb der Proxmox-WebUI?

Was ich dazu aber auch noch wissen muss: Kann ich den zusätzlichen Speicherplatz, den ich mit "Größe anpassen +" zugewiesen habe, auch wieder zurückziehen? Ich habe bisher nur die virtuelle Platte vergrößert aber innerhalb der VM noch kein resise2fs laufen lassen! Daher kann der zusätzliche Speicherplatz auch noch nicht belegt sein

 

[IsThisThingOn]

Ich werde den ZFS-Pool auflösen und zu einem Mirror machen. Das geht hoffentlich innerhalb der Proxmox-WebUI?

Wo hast du denn den boot pool drauf?

Ich persönlich finde, am einfachsten wäre es die Installation Platt zu machen und dann zwei mirrors im stripe (RAID10) zu machen.

Kann ich den zusätzlichen Speicherplatz, den ich mit "Größe anpassen +" zugewiesen habe, auch wieder zurückziehen?

Da bin ich ehrlich gesagt überfragt, aber ich glaube das ist nicht ohne weiteres möglich.
Grundsätzlich ist aber RAW auf ZVOL thin provisioniert, darum ist hoffentlich die VM disk Grösse nicht entscheidend für dich.

 

[whiterabbit]

Ok -- leider klappt das nicht ganz so wie vorgesehen: Ich habe den rpool geräumt und alle virt. Harddisks per Disk-Aktion -> Speicher verschieben woanders zwischengelagert.
Als der rpool leer war, konnte ich ihn innerhalb der WebUI entfernen. Am Ende gab es zwar eine Fehlermeldung "ressource busy" aber der Pool war weg und wird auch nicht mehr von zfs list oder zpool status angezeigt.

Aber wenn ich nun einen neuen ZFS-Pool (mirror) anlegen will, werden mir die freigewordenen Platten gar nicht mehr angezeigt. Die Liste der zur Verfügung stehenden Devices ist einfach leer. Daher die Frage: Warum und wie bekomme ich die zurück?


Zum Glück hatte ich mir kurz vorher noch einen Screenshot der IDs gemacht, so dass man die Platten immerhin wiederfinden und zuordnen kann. Aber mit Bordmitteln ist da offenbar nichts zu machen? Wie geht es hier am sinnvollsten weiter?

Hier sieht man's nochmal: "Alle Disks benutzt" stimmt ja nicht mehr. Ist das ein Bug oder ein Feature?

 

[whiterabbit]

... wie gut, dass der Befehl noch im DokuWiki stand ... ich habe auf einem anderen Server irgendwann schon mal einen ZFS-Pool manuell und nicht über das WebUI erstellt.
Die Befehle lauten so:

zpool create -f -o ashift=12 rpool mirror /dev/sdh /dev/sdg mirror /dev/sdf /dev/sdi

bzw noch besser:

zpool create -f -o ashift=12 rpool mirror /dev/disk/by-id/wwn-0x5000cca02c0c77d0 /dev/disk/by-id/wwn-0x5000cca02c1b1c10  mirror /dev/disk/by-id/wwn-0x5000cca02c1b7a44 /dev/disk/by-id/wwn-0x
5000cca02c65dd28
zfs set compression=lz4 rpool
zpool add rpool cache /dev/disk/by-id/wwn-0x5002538e0006d0bf
zpool status

 

[news]

Es fehlt zfs set atime=[on|off] <pool> und zfs set quota=<80% max-size> <pool>.

 

[whiterabbit]

Oh, wusste bisher nicht, dass Quota auch so setzbar ist . Und zum Thema atime: Was ist da die Empfehlung? On oder Off?
(hier geht es die ganze Zeit um eine Nextcloud ... also zig Dateien von zig Usern)
Und wo ich schon dabei bin: Bei der Neu-Einrichtung des Pools unter Rechenzentrum -> Storage ist (jetzt?) 16k als Default-Blockgröße eingestellt.
So lassen oder ändern? Ich meine, dass es vorher auf 8k stand...

 

[IsThisThingOn]

hier geht es die ganze Zeit um eine Nextcloud

Noch ein Einschub.

Wenn du die Nextcloud Daten auf einer VM Disk (zvol) speicherst, liegen alle Daten auf einem starren, fixen, 16k blockstorage.
Wenn du die Daten aber auf einem Dataset speicherst, liegen alle Daten auf einem variablen record size, der per default 128k als max Obergrenze hat.

 

[whiterabbit]

Ok -- was hat das in der Praxis für Konsequenzen? Performance? Mehr/weniger Plattenplatzbelegung oder worauf willst Du hinaus?

 

[IsThisThingOn]

Performance, Kompression, pool geometrie, padding, Metadaten, Einsatz von special vdev um kleine Dateien oder Metadaten zu speichern, die Möglichkeit die Daten im Dataset anzusehen ohne eine Disk mounten zu müssen, von dort Backups nach S3 machen oder rsync...

Wie relevant das für dich ist, kann ich nicht sagen. Vermutlich jammern auf hohem Niveau

 

[whiterabbit]

Das Thema gab es ja vor längerer Zeit schon mal hier im Forum ... ich kann das ZVOL nicht nachträglich in ein Dataset umwandeln, nehme ich an? Zumindest war das der Stand der Dinge hier.

 

[IsThisThingOn]

Nee, das geht nicht

 

[whiterabbit]

Hier noch ein paar Dinge zu den noch offenen Fragen:

Was für ein "cache"?

Ich habe den L2ARC-Cache (auf einer Enterprise-SSD) wieder aktiviert, da die anderen Platten noch drehende Spindeln sind und daher entsprechend langsamer.

zpool add rpool cache /dev/disk/by-id/wwn-0x5002538e0006d0bf

Ob das in diesem Fall was bringt oder nicht, kann ich schlecht sagen. Im Forum findet man dazu: https://forum.proxmox.com/threads/zfs-cache-nachträglich-einrichten.81602/

Du hast aber nicht deduplication aktiv?!

Dazu habe ich das hier gefunden: https://de.wikibooks.org/wiki/ZFS_auf_Linux/_Deduplizierung
Auf dem Server (jetzt also mit dem neu eingerichteten ZFS-Pool als mirror):

zpool list

NAME                  SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
rpool                3.25T  1.50T  1.75T        -         -     0%    46%  1.00x    ONLINE  -

Wo hast du denn den boot pool drauf?

Das System befindet sich auf diesem Server auf getrennten SSD-Platten (ebenfalls ein ZFS-mirror). Das ZFS-Storage, um das es hier ging, ist also völlig getrennt vom Boot-Pool. Daher kam eine Neuinstallation in diesem Fall auch nicht in Betracht.

 

[IsThisThingOn]

Ich habe den L2ARC-Cache

L2ARC wird vermutlich nix bringen. Bei Blockstorage ist L2ARC noch schwieriger.
Würde ich weglassen.

Ob das in diesem Fall was bringt oder nicht, kann ich schlecht sagen.

Du kannst mal schauen, wie hoch dein ARC hit ratio ist.
Oder deine L2ARC hit ratio.

Dazu habe ich das hier gefunden

Ich werte dies mal als "nein".
Gut so.

So grundsätzlich hast du halt zwei Arten von Daten.
- Applikation/VM/DB Daten
Wenn die einigermassen anständig flutschen sollen, brauchst du ein SSD mirror dafür.
- Grosse Dateien in Nextcloud.
Dort kannst du auch schon mit einfachen HDDs und dataset ein 1GBit/ NIC ausreizen.

 

[whiterabbit]

Du kannst mal schauen, wie hoch dein ARC hit ratio ist.

Ok ... ich habe den Befehl

arc_summary

laufen lassen.
Hier das Ergebnis:

Spoiler: arc_summary

 ~ # arc_summary

------------------------------------------------------------------------
ZFS Subsystem Report                            Sun Feb 16 15:08:31 2025
Linux 6.8.12-8-pve                                            2.2.7-pve1
Machine: pve-m4 (x86_64)                                      2.2.7-pve1

ARC status:                                                      HEALTHY
        Memory throttle count:                                         0

ARC size (current):                                    96.4 %   61.7 GiB
        Target size (adaptive):                       100.0 %   64.0 GiB
        Min size (hard limit):                          6.2 %    4.0 GiB
        Max size (high water):                           16:1   64.0 GiB
        Anonymous data size:                          < 0.1 %    1.1 MiB
        Anonymous metadata size:                      < 0.1 %  512.0 KiB
        MFU data target:                               32.5 %   19.3 GiB
        MFU data size:                                 15.7 %    9.4 GiB
        MFU ghost data size:                                    94.1 MiB
        MFU metadata target:                            9.4 %    5.6 GiB
        MFU metadata size:                              0.6 %  339.6 MiB
        MFU ghost metadata size:                                 0 Bytes
        MRU data target:                               48.7 %   29.0 GiB
        MRU data size:                                 76.7 %   45.6 GiB
        MRU ghost data size:                                     4.6 GiB
        MRU metadata target:                            9.4 %    5.6 GiB
        MRU metadata size:                              7.1 %    4.2 GiB
        MRU ghost metadata size:                                 0 Bytes
        Uncached data size:                             0.0 %    0 Bytes
        Uncached metadata size:                         0.0 %    0 Bytes
        Bonus size:                                   < 0.1 %    8.1 MiB
        Dnode cache target:                            10.0 %    6.4 GiB
        Dnode cache size:                               0.5 %   29.5 MiB
        Dbuf size:                                      0.1 %   50.8 MiB
        Header size:                                    1.6 %  996.0 MiB
        L2 header size:                                 1.8 %    1.1 GiB
        ABD chunk waste size:                         < 0.1 %  353.0 KiB

ARC hash breakdown:
        Elements max:                                              19.9M
        Elements current:                              83.1 %      16.5M
        Collisions:                                               605.7M
        Chain max:                                                     9
        Chains:                                                     2.9M

ARC misc:
        Deleted:                                                  822.0M
        Mutex misses:                                             192.8k
        Eviction skips:                                            10.4M
        Eviction skips due to L2 writes:                               0
        L2 cached evictions:                                     9.2 TiB
        L2 eligible evictions:                                   3.2 TiB
        L2 eligible MFU evictions:                      0.8 %   27.6 GiB
        L2 eligible MRU evictions:                     99.2 %    3.1 TiB
        L2 ineligible evictions:                                28.0 KiB

ARC total accesses:                                                 2.4G
        Total hits:                                    73.0 %       1.8G
        Total I/O hits:                                 5.3 %     129.0M
        Total misses:                                  21.7 %     526.9M

ARC demand data accesses:                              28.3 %     687.9M
        Demand data hits:                              79.8 %     548.9M
        Demand data I/O hits:                          18.6 %     128.0M
        Demand data misses:                             1.6 %      10.9M

ARC demand metadata accesses:                          49.9 %       1.2G
        Demand metadata hits:                         100.0 %       1.2G
        Demand metadata I/O hits:                     < 0.1 %     514.4k
        Demand metadata misses:                       < 0.1 %       5.8k

ARC prefetch data accesses:                            21.7 %     526.6M
        Prefetch data hits:                             1.9 %      10.3M
        Prefetch data I/O hits:                         0.1 %     464.9k
        Prefetch data misses:                          98.0 %     515.9M

ARC prefetch metadata accesses:                       < 0.1 %       1.0M
        Prefetch metadata hits:                        97.0 %     977.6k
        Prefetch metadata I/O hits:                     1.4 %      14.2k
        Prefetch metadata misses:                       1.6 %      16.5k

ARC predictive prefetches:                            100.0 %     527.5M
        Demand hits after predictive:                  75.4 %     397.6M
        Demand I/O hits after predictive:              24.3 %     128.1M
        Never demanded after predictive:                0.3 %       1.8M

ARC prescient prefetches:                             < 0.1 %     205.7k
        Demand hits after prescient:                   99.0 %     203.8k
        Demand I/O hits after prescient:              < 0.1 %         14
        Never demanded after prescient:                 1.0 %       2.0k

ARC states hits of all accesses:
        Most frequently used (MFU):                    54.6 %       1.3G
        Most recently used (MRU):                      18.4 %     446.0M
        Most frequently used (MFU) ghost:             < 0.1 %       1.0M
        Most recently used (MRU) ghost:                 0.1 %       1.3M
        Uncached:                                       0.0 %          0

DMU predictive prefetcher calls:                                    2.0G
        Stream hits:                                   49.4 %       1.0G
        Hits ahead of stream:                           0.5 %      10.0M
        Hits behind stream:                             9.2 %     189.0M
        Stream misses:                                 40.9 %     836.0M
        Streams limit reached:                          3.1 %      26.0M
        Stream strides:                                             6.0M
        Prefetches issued                                         528.1M

L2ARC status:                                                    HEALTHY
        Low memory aborts:                                             0
        Free on write:                                             23.3k
        R/W clashes:                                                   0
        Bad checksums:                                                 0
        Read errors:                                                   0
        Write errors:                                                  0

L2ARC size (adaptive):                                         226.9 GiB
        Compressed:                                    94.5 %  214.3 GiB
        Header size:                                    0.5 %    1.1 GiB
        MFU allocated size:                             0.3 %  576.7 MiB
        MRU allocated size:                            99.5 %  213.2 GiB
        Prefetch allocated size:                        0.2 %  524.6 MiB
        Data (buffer content) allocated size:          98.1 %  210.2 GiB
        Metadata (buffer content) allocated size:       1.9 %    4.1 GiB

L2ARC breakdown:                                                  417.6M
        Hit ratio:                                      1.7 %       7.1M
        Miss ratio:                                    98.3 %     410.4M

L2ARC I/O:
        Reads:                                       78.7 GiB       7.1M
        Writes:                                       9.2 TiB     419.0k

L2ARC evicts:
        L1 cached:                                                 11.0M
        While reading:                                                 0

Solaris Porting Layer (SPL):
        spl_hostid                                                     0
        spl_hostid_path                                      /etc/hostid
        spl_kmem_alloc_max                                       1048576
        spl_kmem_alloc_warn                                        65536
        spl_kmem_cache_kmem_threads                                    4
        spl_kmem_cache_magazine_size                                   0
        spl_kmem_cache_max_size                                       32
        spl_kmem_cache_obj_per_slab                                    8
        spl_kmem_cache_slab_limit                                  16384
        spl_max_show_tasks                                           512
        spl_panic_halt                                                 0
        spl_schedule_hrtimeout_slack_us                                0
        spl_taskq_kick                                                 0
        spl_taskq_thread_bind                                          0
        spl_taskq_thread_dynamic                                       1
        spl_taskq_thread_priority                                      1
        spl_taskq_thread_sequential                                    4
        spl_taskq_thread_timeout_ms                                 5000

Tunables:
       [weggelassen, da ich nicht mehr als 16.000 Zeichen posten kann]

ZIL committed transactions:                                       236.0k
        Commit requests:                                           30.5k
        Flushes to stable storage:                                 30.5k
        Transactions to SLOG storage pool:            0 Bytes          0
        Transactions to non-SLOG storage pool:        2.2 GiB      38.8k

Ob der Wert unter "Hit Ratio" nun kritisch/gut/schlecht ist, kann ich aber leider nicht ohne weiteres sagen...

Die Nextcloud wird von vielen Leuten genutzt (Größenordnung ~1000). Die meisten User packen da Backups hin (Einzelfiles, ~4GB). Aber natürlich gibt es auch viele kleine Dateien.