Diskrepanz von freien Platz auf zpool

[bforpc]

Hallo,

wie kann das denn sein:

~ zfs list -o space
NAME                                  AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
store                                 5.86T  21.8T        0B    166K             0B      21.8T
store/proxmox                         5.86T  21.8T        0B    153K             0B      21.8T
store/proxmox/vm                      5.86T  21.8T        0B    153K             0B      21.8T
store/proxmox/vm/vm-60100-disk-0      5.86T  21.0T      718G   20.3T             0B      1.84G
store/proxmox/vm/vm-60100-disk-0-ssd  5.86T   723G     78.5G    644G             0B         0B
store/proxmox/vm/vm-62101-disk-0      5.86T  3.68G      341M   3.35G             0B         0B
store/proxmox/vm/vm-62102-disk-0      5.86T   131G      166M    131G             0B         0B

und

~ zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
store  34.8T  27.3T  7.50T        -         -     1%    78%  1.00x    ONLINE  -

Infos zum zpoool:

 pool: store
 state: ONLINE
config:

    NAME                                                      STATE     READ WRITE CKSUM
    store                                                     ONLINE       0     0     0
      raidz1-0                                                ONLINE       0     0     0
        nvme-Micron_7450_MTFDKCC7T6TFR_22313A89246F-part5     ONLINE       0     0     0
        nvme-SAMSUNG_MZQL27T6HBLA-00A07_S6CKNT0W602951-part5  ONLINE       0     0     0
        nvme-SAMSUNG_MZQL27T6HBLA-00A07_S6CKNT0W711642-part5  ONLINE       0     0     0
        nvme-SAMSUNG_MZQL27T6HBLA-00A07_S6CKNT0W602281-part5  ONLINE       0     0     0
        nvme-SAMSUNG_MZQL27T6HBLA-00A07_S6CKNT0W711047-part5  ONLINE       0     0     0

errors: No known data errors

Es wurde seit langem nichts gelöscht oder großartig übertragen.
Wo ist der Plattenplatz?

 

[fabian]

sh "man zfsprops" vs "man zpoolprops"

available The amount of space available to the dataset and all its children, assuming that there is no other activity in
the pool. Because space is shared within a pool, availability can be limited by any number of factors, in‐
cluding physical pool size, quotas, reservations, or other datasets within the pool.

[..]

used The amount of space consumed by this dataset and all its descendents. This is the value that is checked
against this dataset's quota and reservation. The space used does not include this dataset's reservation, but
does take into account the reservations of any descendent datasets. The amount of space that a dataset con‐
sumes from its parent, as well as the amount of space that is freed if this dataset is recursively destroyed,
is the greater of its space used and its reservation.

The used space of a snapshot (see the Snapshots section of zfsconcepts(7)) is space that is referenced exclu‐
sively by this snapshot. If this snapshot is destroyed, the amount of used space will be freed. Space that
is shared by multiple snapshots isn't accounted for in this metric. When a snapshot is destroyed, space that
was previously shared with this snapshot can become unique to snapshots adjacent to it, thus changing the used
space of those snapshots. The used space of the latest snapshot can also be affected by changes in the file
system. Note that the used space of a snapshot is a subset of the written space of the snapshot.

free The amount of free space available in the pool. By contrast, the zfs(8) available property describes how much new
data can be written to ZFS filesystems/volumes. The zpool free property is not generally useful for this purpose,
and can be substantially more than the zfs available space. This discrepancy is due to several factors, including
raidz parity; zfs reservation, quota, refreservation, and refquota properties; and space set aside by
spa_slop_shift (see zfs(4) for more information).

 

[bforpc]

Soweit so gut ... aber auf welche Daten kann ich mich dann verlassen. Wenn

The zpool free property is not generally useful for this purpose

das so ist, wozu gibt es das dann?

"5.86T + 21.0T" = ~ 27TB
Das entspricht ja in etwa dem "ALLOC" Speicherplatz

NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
store 34.8T 27.3T 7.50T - - 1% 78% 1.00x ONLINE -

Abschliessende Frage: Mit welchem Befehl sehe ich, wieviel Platz auf dem Storage wirklich frei und benutzbar ist?

Bfo

 

[fabian]

naja zum beispiel um zu analysieren, wie hoch der overhead im konkreten fall ist

wenn du wissen willst wieviel platz noch zum schreiben da ist - dafuer ist "available" da.

 

[bforpc]

Hallo fabian,

danke für die Antwort. Das ist aber extrem ... unschön ... (was nur eine Feststellung für mich ist). Das könnte man doch sicher auch besser lösen. Allerdings ist das kein Thema mehr hier im Forum. THX.

Bfo

 

[Falk R.]

Hallo fabian,

danke für die Antwort. Das ist aber extrem ... unschön ... (was nur eine Feststellung für mich ist). Das könnte man doch sicher auch besser lösen. Allerdings ist das kein Thema mehr hier im Forum. THX.

Bfo

Das Problem ist die hohe Komplexität / Featureanzahl bei ZFS. Die Informationen sind für einige Menschen alle wichtig und entweder guckt man einfach auf die GUI und vertraut auf PVE oder man macht sich ganz tief mit ZFS vertraut.

 

[ubu]

Wenn Kompression aktiviert ist, kann man mehr Daten speichern als physikalisch Plattenplatz vorhanden ist, da die Kompression aber von der Komprimierbarkeit abhängt kann man vorher nicht sagen wie viel mehr

PS
Vorsicht bei Migration von ZFS mit Kompression auf andere Speichertypen, mindestens 30% mehr Platzverbrauch einplanen

 

[Falk R.]

Bei Datenbankservern hatte ich schon Komprimierungen bis zu 1:3.
Habe ich nicht einkalkuliert, dadurch hat der Kunde jetzt mehr Reserve.
Also, Komprimierung nutzen aber nicht fest verplanen.

 

[MH_MUC]

Okay was ist dann ein guter Weg um eine Warnung zu generieren, wenn der Speicherplatz eng wird? Das Avail ist ja immer in wechselnden Einheiten angegeben....
Wollte das gerade basteln nachdem ich kürzlich krasse Probleme hatte mit einem Server.

 

[fabian]

wie meinst du? du kannst zfs sagen dass speicherangaben immer in bytes sein sollen ("-p" fuer "parsable"), z.b. bei "zfs list .." oder "zfs get .."

 

[MH_MUC]

Hi Fabian, danke für den TIpp. Ich muss mich an den Thread noch einmal dranhängen, nachdem ich neulich ein größeres Problem hatte, das sogar zu Dataloss führte (vgl. https://forum.proxmox.com/threads/crash-with-data-loss-in-a-2node-cluster.139660/)

Ich wollte mir gerade ein Script bauen, das Alerts versendet, wenn der Speicher knapp wird. Für meinen data-pool sehe ich in der PVE GUI eine Usage von 80% (1.5 TB von 1.9 TV belegt).

Ein "zpoollist" ergibt allerdings folgendes Bild:

zpool list
NAME        SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
data-pool  1.81T   525G  1.30T        -         -    31%    28%  1.00x    ONLINE  -
rpool       928G   470G   458G        -         -    16%    50%  1.00x    ONLINE  -

Wie passt das zusammen? Deiner Aussage nach müsste ich mich auf das "Free" doch verlassen können - also 1.3 TB schreiben in den Pool.

Ich werde mich noch damit auseinandersetzen müssen warum bei dem data-pool so hohe Werte in der USEDREFRESERV Spalte stehen...

zfs list -o space
NAME                         AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
data-pool                     364G  1.40T        0B     96K             0B      1.40T
data-pool/subvol-100-disk-0   364G  22.5G     26.9M   22.5G             0B         0B
data-pool/vm-101-disk-0       879G   868G        0B    352G           516G         0B
data-pool/vm-101-disk-1       518G   203G        0B   48.5G           155G         0B
data-pool/vm-103-disk-0       396G  38.9G     5.80M   5.87G          33.0G         0B
data-pool/vm-112-disk-0       467G   152G        0B   48.4G           103G         0B
data-pool/vm-251-disk-0       467G   151G        0B   47.7G           103G         0B
rpool                         429G   470G        0B    104K             0B       470G
rpool/ROOT                    429G  3.81G        0B     96K             0B      3.81G
rpool/ROOT/pve-1              429G  3.81G        0B   3.81G             0B         0B
rpool/data                    429G   466G        0B     96K             0B       466G
rpool/data/vm-102-disk-0      429G  6.37G        0B   6.37G             0B         0B
rpool/data/vm-109-disk-0      429G   460G        0B    460G             0B         0B

Danke auf jeden Fall schon einmal für die Hilfe soweit.

 

[fabian]

in "man zfsprops" steht recht gut beschrieben, was welche spalte bedeutet. aus "zfs" sicht sind auch dinge wie reservierter platz, quotas usw "belegt". aus "zpool" sicht nicht - reservierter, aber noch nicht beschriebener speicherplatz ist nur "logisch" belegt, nicht aber "physisch" auf den platten

 

[MH_MUC]

Falls jemand auf diesen Thread stoßen sollte:
Für den nachträglich über die Proxmox-GUI angelegten "data-pool" war in /etc/pve/storage.cfg das "sparse"-value nicht auf 1. Dadurch habe ich bei dem Pool versehentlich auf thin-provisioning verzichtet. Offenbar führt das dazu, dass für das Volume riesige Reservations angelegt werden:

zfs get refreservation
NAME                                                        PROPERTY        VALUE      SOURCE
data-pool                                                   refreservation  none       default
data-pool/subvol-100-disk-0                                 refreservation  none       default
data-pool/subvol-100-disk-0@__replicate_100-0_1705658401__  refreservation  -          -
data-pool/vm-101-disk-0                                     refreservation  516G       received
data-pool/vm-101-disk-0@__replicate_101-0_1705658405__      refreservation  -          -
data-pool/vm-101-disk-1                                     refreservation  155G       received
data-pool/vm-101-disk-1@__replicate_101-0_1705658405__      refreservation  -          -
data-pool/vm-103-disk-0                                     refreservation  33.0G      received
data-pool/vm-103-disk-0@__replicate_103-0_1705658409__      refreservation  -          -
data-pool/vm-112-disk-0                                     refreservation  103G       received
data-pool/vm-112-disk-0@__replicate_112-0_1705658438__      refreservation  -          -
data-pool/vm-251-disk-0                                     refreservation  103G       received
data-pool/vm-251-disk-0@__replicate_251-0_1705658452__      refreservation  -          -
rpool                                                       refreservation  none       default
rpool/ROOT                                                  refreservation  none       default
rpool/ROOT/pve-1                                            refreservation  none       default
rpool/data                                                  refreservation  none       default
rpool/data/vm-109-disk-0                                    refreservation  none       default
rpool/data/vm-109-disk-0@__replicate_109-0_1705658403__     refreservation  -          -

Ich habe das Sparse-Value nachträglich hinzugefügt und bei den schon existierenden Volumes mit

zfs set refreservation=none data-pool/vm-101-disk-0

die Reservation entfernt.