strano rapporto sull'utilizzo dello spazio su disco ZFS per un ZVOL

8

Abbiamo un ZVOL 100G su un host FreeBSD 10.0-CURRENT che afferma di usare 176G di spazio su disco:

root@storage01:~ # zfs get all zroot/DATA/vtest
NAME              PROPERTY              VALUE                  SOURCE
zroot/DATA/vtest  type                  volume                 -
zroot/DATA/vtest  creation              Fri May 24 20:44 2013  -
zroot/DATA/vtest  used                  176G                   -
zroot/DATA/vtest  available             10.4T                  -
zroot/DATA/vtest  referenced            176G                   -
zroot/DATA/vtest  compressratio         1.00x                  -
zroot/DATA/vtest  reservation           none                   default
zroot/DATA/vtest  volsize               100G                   local
zroot/DATA/vtest  volblocksize          8K                     -
zroot/DATA/vtest  checksum              fletcher4              inherited from zroot
zroot/DATA/vtest  compression           off                    default
zroot/DATA/vtest  readonly              off                    default
zroot/DATA/vtest  copies                1                      default
zroot/DATA/vtest  refreservation        none                   local
zroot/DATA/vtest  primarycache          all                    default
zroot/DATA/vtest  secondarycache        all                    default
zroot/DATA/vtest  usedbysnapshots       0                      -
zroot/DATA/vtest  usedbydataset         176G                   -
zroot/DATA/vtest  usedbychildren        0                      -
zroot/DATA/vtest  usedbyrefreservation  0                      -
zroot/DATA/vtest  logbias               latency                default
zroot/DATA/vtest  dedup                 off                    default
zroot/DATA/vtest  mlslabel                                     -
zroot/DATA/vtest  sync                  standard               default
zroot/DATA/vtest  refcompressratio      1.00x                  -
zroot/DATA/vtest  written               176G                   -
zroot/DATA/vtest  logicalused           87.2G                  -
zroot/DATA/vtest  logicalreferenced     87.2G                  -
root@storage01:~ #

Sembra un bug, come può consumare più del suo volsizese non ha istantanee, prenotazioni e figli? O forse ci manca qualcosa?

UPD:

Risultati di zpool status -v:

root@storage01:~ # zpool status -v
  pool: zroot
 state: ONLINE
  scan: scrub repaired 0 in 0h6m with 0 errors on Thu May 30 05:45:11 2013
config:

        NAME           STATE     READ WRITE CKSUM
        zroot          ONLINE       0     0     0
          raidz2-0     ONLINE       0     0     0
            gpt/disk0  ONLINE       0     0     0
            gpt/disk1  ONLINE       0     0     0
            gpt/disk2  ONLINE       0     0     0
            gpt/disk3  ONLINE       0     0     0
            gpt/disk4  ONLINE       0     0     0
            gpt/disk5  ONLINE       0     0     0
        cache
          ada0s2       ONLINE       0     0     0

errors: No known data errors
root@storage01:~ #

Risultati di zpool list:

root@storage01:~ # zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
zroot  16.2T   288G  16.0T     1%  1.05x  ONLINE  -
root@storage01:~ #

Risultati di zfs list:

root@storage01:~ # zfs list
NAME                            USED  AVAIL  REFER  MOUNTPOINT
zroot                           237G  10.4T   288K  /
zroot/DATA                      227G  10.4T   352K  /DATA
zroot/DATA/NFS                  288K  10.4T   288K  /DATA/NFS
zroot/DATA/hv                  10.3G  10.4T   288K  /DATA/hv
zroot/DATA/hv/hv001            10.3G  10.4T   144K  -
zroot/DATA/test                 288K  10.4T   288K  /DATA/test
zroot/DATA/vimage              41.3G  10.4T   288K  /DATA/vimage
zroot/DATA/vimage/vimage_001   41.3G  10.5T  6.47G  -
zroot/DATA/vtest                176G  10.4T   176G  -
zroot/SYS                      9.78G  10.4T   288K  /SYS
zroot/SYS/ROOT                  854M  10.4T   854M  /
zroot/SYS/home                 3.67G  10.4T  3.67G  /home
zroot/SYS/tmp                   352K  10.4T   352K  /tmp
zroot/SYS/usr                  4.78G  10.4T   427M  /usr
zroot/SYS/usr/local             288K  10.4T   288K  /usr/local
zroot/SYS/usr/obj              3.50G  10.4T  3.50G  /usr/obj
zroot/SYS/usr/ports             895K  10.4T   320K  /usr/ports
zroot/SYS/usr/ports/distfiles   288K  10.4T   288K  /usr/ports/distfiles
zroot/SYS/usr/ports/packages    288K  10.4T   288K  /usr/ports/packages
zroot/SYS/usr/src               887M  10.4T   887M  /usr/src
zroot/SYS/var                   511M  10.4T  1.78M  /var
zroot/SYS/var/crash             505M  10.4T   505M  /var/crash
zroot/SYS/var/db               1.71M  10.4T  1.43M  /var/db
zroot/SYS/var/db/pkg            288K  10.4T   288K  /var/db/pkg
zroot/SYS/var/empty             288K  10.4T   288K  /var/empty
zroot/SYS/var/log               647K  10.4T   647K  /var/log
zroot/SYS/var/mail              296K  10.4T   296K  /var/mail
zroot/SYS/var/run               448K  10.4T   448K  /var/run
zroot/SYS/var/tmp               304K  10.4T   304K  /var/tmp
root@storage01:~ #

Aggiornamento 2:

Abbiamo creato un numero di ZVOL con parametri diversi e utilizzato ddper spostare il contenuto. Abbiamo notato un'altra cosa strana, l'uso del disco era normale per ZVOL con 16k e 128k volblocksizeed è rimasto anormale per uno ZVOL con 8k volblocksizeanche dopo dd(quindi questo non è un problema di frammentazione):

root@storage01:~ # zfs get all zroot/DATA/vtest-3
NAME                PROPERTY              VALUE                  SOURCE
zroot/DATA/vtest-3  type                  volume                 -
zroot/DATA/vtest-3  creation              Fri May 31  7:35 2013  -
zroot/DATA/vtest-3  used                  201G                   -
zroot/DATA/vtest-3  available             10.2T                  -
zroot/DATA/vtest-3  referenced            201G                   -
zroot/DATA/vtest-3  compressratio         1.00x                  -
zroot/DATA/vtest-3  reservation           none                   default
zroot/DATA/vtest-3  volsize               100G                   local
zroot/DATA/vtest-3  volblocksize          8K                     -
zroot/DATA/vtest-3  checksum              fletcher4              inherited from zroot
zroot/DATA/vtest-3  compression           off                    default
zroot/DATA/vtest-3  readonly              off                    default
zroot/DATA/vtest-3  copies                1                      default
zroot/DATA/vtest-3  refreservation        103G                   local
zroot/DATA/vtest-3  primarycache          all                    default
zroot/DATA/vtest-3  secondarycache        all                    default
zroot/DATA/vtest-3  usedbysnapshots       0                      -
zroot/DATA/vtest-3  usedbydataset         201G                   -
zroot/DATA/vtest-3  usedbychildren        0                      -
zroot/DATA/vtest-3  usedbyrefreservation  0                      -
zroot/DATA/vtest-3  logbias               latency                default
zroot/DATA/vtest-3  dedup                 off                    default
zroot/DATA/vtest-3  mlslabel                                     -
zroot/DATA/vtest-3  sync                  standard               default
zroot/DATA/vtest-3  refcompressratio      1.00x                  -
zroot/DATA/vtest-3  written               201G                   -
zroot/DATA/vtest-3  logicalused           100G                   -
zroot/DATA/vtest-3  logicalreferenced     100G                   -
root@storage01:~ #

e

root@storage01:~ # zfs get all zroot/DATA/vtest-16
NAME                 PROPERTY              VALUE                  SOURCE
zroot/DATA/vtest-16  type                  volume                 -
zroot/DATA/vtest-16  creation              Fri May 31  8:03 2013  -
zroot/DATA/vtest-16  used                  102G                   -
zroot/DATA/vtest-16  available             10.2T                  -
zroot/DATA/vtest-16  referenced            101G                   -
zroot/DATA/vtest-16  compressratio         1.00x                  -
zroot/DATA/vtest-16  reservation           none                   default
zroot/DATA/vtest-16  volsize               100G                   local
zroot/DATA/vtest-16  volblocksize          16K                    -
zroot/DATA/vtest-16  checksum              fletcher4              inherited from zroot
zroot/DATA/vtest-16  compression           off                    default
zroot/DATA/vtest-16  readonly              off                    default
zroot/DATA/vtest-16  copies                1                      default
zroot/DATA/vtest-16  refreservation        102G                   local
zroot/DATA/vtest-16  primarycache          all                    default
zroot/DATA/vtest-16  secondarycache        all                    default
zroot/DATA/vtest-16  usedbysnapshots       0                      -
zroot/DATA/vtest-16  usedbydataset         101G                   -
zroot/DATA/vtest-16  usedbychildren        0                      -
zroot/DATA/vtest-16  usedbyrefreservation  886M                   -
zroot/DATA/vtest-16  logbias               latency                default
zroot/DATA/vtest-16  dedup                 off                    default
zroot/DATA/vtest-16  mlslabel                                     -
zroot/DATA/vtest-16  sync                  standard               default
zroot/DATA/vtest-16  refcompressratio      1.00x                  -
zroot/DATA/vtest-16  written               101G                   -
zroot/DATA/vtest-16  logicalused           100G                   -
zroot/DATA/vtest-16  logicalreferenced     100G                   -
root@storage01:~ #
freebsd  zfs  zvol 
— alex
fonte
Sospettiamo che questa possa essere una frammentazione, ma non sappiamo come dimostrarlo
— Alex,
Potrebbe essere correlato a istantanee?
— Steve Wills,
No, non abbiamo istantanee su questo volume
— Alex,
Triste quando vedo la compressione disabilitata su volumi / filesystem ZFS. Ad ogni modo, puoi pubblicare zpool status -ve zpool liste zfs list?
— ewwhite,
1
Da tutto ciò che posso vedere in questo, sembra un bug. L '"uso" di uno zvol con una volsize di 100 G non dovrebbe superare i 100 G se non ci sono bambini o riserve o simili. Forse era in realtà una dimensione vols di oltre 200 GB e hai cambiato il parametro volsize? In caso contrario, FreeBSD-10.0 non è ancora una versione di produzione; segnalare un bug con loro.
— Nex7,

Risposte:

2

VOLSIZE rappresenta la dimensione del volume così come sarà vista dai client, non la dimensione del volume memorizzata nel pool.

Questa differenza può provenire da più fonti:

  • spazio richiesto per i metadati
  • spazio richiesto per l'archiviazione di più copie (i parametri "copie")
  • "spazio sprecato" a causa dell'imbottitura durante l'allineamento di blocchi di dimensioni "volblocksize" alla struttura vdev; per struttura vdev intendo due parametri: numero di dischi in raidz-N e dimensione del blocco fisico dei dispositivi.

Quando si crea un volume, ZFS sarà stimare quanto spazio avrebbe bisogno di utilizzare al fine di essere in grado di presentare un volume di "volsize" ai propri clienti. Puoi vedere quella differenza nei volumi vtest-16 e vtest-3 (dove la conservazione è di 102 GB e il volume è di 100 GB). Il calcolo è disponibile in libzfs_dataset.c (zvol_volsize_to_reservation (uint64_t volsize, nvlist_t * props))

Ciò che non viene preso in considerazione da quel calcolo è la terza fonte. La terza fonte ha un impatto limitato sui vdev creati con dischi con settori a 512 byte. Dai miei esperimenti (l'ho provato riempiendo un intero zvol per verificarlo) fa davvero la differenza quando il vdev viene creato su dischi di settore 4K più recenti.

Un'altra cosa che ho scoperto nei miei esperimenti è che avere i mirror non mostra differenze tra la rigenerazione calcolata e ciò che finisce per essere usato.

Questi sono i miei risultati quando utilizzo unità 4K con volumi con Volblocksize predefinito (8 KB). La prima colonna rappresenta il numero di dischi in un vdev:

    raidz1  raidz2
3   135%    101%
4   148%    148%
5   162%    181%
6   162%    203%
7   171%    203%
8   171%    217%
9   181%    232%
10  181%    232%
11  181%    232%
12  181%    232%

Questi sono i miei risultati quando utilizzo unità di settore da 512 byte e dimensioni volblock predefinite di 8 KB. La prima colonna rappresenta il numero di dischi in un vdev:

    raidz1  raidz2
3   101%    101%
4   104%    104%
5   101%    113%
6   105%    101%
7   108%    108%
8   110%    114%
9   101%    118%
10  102%    106%
11  103%    108%
12  104%    110%

Le mie conclusioni sono le seguenti:

  • Non utilizzare unità 4K
  • Se hai davvero bisogno di usarli, crea il volume usando volblocksize maggiore o uguale a 32K; Vi è un impatto trascurabile sulle prestazioni e un sovraccarico di utilizzo dello spazio trascurabile (blocchi di dimensioni maggiori richiedono meno imbottitura per allinearsi correttamente).
  • Preferisci strisce di specchi per le tue piscine; Questo layout ha sia vantaggi prestazionali che meno sorprese legate allo spazio come questa.
  • La stima è chiaramente errata per i casi descritti sopra, e questo è un bug in zfs.
— Dan Vatca
fonte
2
L'uso di unità 4k in un pool con ashift=9è noto per causare problemi. Questa non è una novità. La modifica della dimensione del blocco non allinea neanche le unità. La soluzione corretta è quella di creare il pool con ashift=12.
— Chris S,
ashift=12su unità 4K non risolve questo problema; infatti, su uno zpool con ashift=12, 5 pezzi di unità 4K e un raidz, lo spazio consumato è vicino a quello sopra menzionato, ad esempio il volume 7T consuma 11T.
— drookie,
-1

Se sto leggendo bene, in realtà hai logicalreferenced87,6 GB di dati sul volume. Il numero di 170 GB che stai visualizzando è lo spazio fisico utilizzato dai dati. Quindi, se hai le tue unità speculari, mi aspetto referenceddi essere circa 2x logicalreferenced.

— collo lungo
fonte
Hmm, un altro FS sullo stesso pool ha referenced 3.50Ge logicalreferenced 3.00Gquindi il rapporto 2x non è coerente tra gli FS sul pool.
— Alex,
A proposito, la piscina raidz2non è un semplice specchio
— Alex,
Ya, ho appena fatto alcuni test rapidi su una VM e la mia teoria non ha retto.
— collo lungo,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.