étrange rapport d'utilisation de l'espace disque ZFS pour un ZVOL

8

Nous avons un ZVOL 100G sur un hôte FreeBSD 10.0-CURRENT qui prétend utiliser 176G d'espace disque:

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:~ #

Cela ressemble à un bug, comment peut-il consommer plus que le sien volsizes'il n'a pas d'instantanés, de réservations et d'enfants? Ou peut-être qu'il nous manque quelque chose?

Mise à jour:

Résultats de 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:~ #

Résultats de 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:~ #

Résultats de 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:~ #

Upd 2:

Nous avons créé un certain nombre de ZVOL avec différents paramètres et utilisés ddpour déplacer le contenu. Nous avons remarqué une autre chose étrange, l'utilisation du disque était normale pour les ZVOL avec 16k et 128k volblocksizeet cela restait anormal pour un ZVOL avec 8k volblocksizemême après dd(donc ce n'est pas un problème de fragmentation):

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:~ #

et

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
la source
Nous soupçonnons que cela peut être une fragmentation, mais nous ne savons pas comment le prouver
Alex
Pourrait-il être lié à des instantanés?
Steve Wills
Non, nous n'avons pas d'instantanés sur ce volume
Alex
Triste quand je vois la compression désactivée sur les volumes / systèmes de fichiers ZFS. Quoi qu'il en soit, pouvez-vous publier zpool status -vet zpool listet zfs list?
ewwhite
1
D'après tout ce que je peux voir, cela ressemble à un bug. L '«utilisation» d'un zvol avec une taille de vol de 100G ne doit pas dépasser largement les 100G s'il n'y a pas d'enfants ou de réserves ou similaires. Peut-être s'agissait-il en fait d'une taille de vol de plus de 200 Go et vous avez modifié le paramètre volsize? Sinon, FreeBSD-10.0 n'est pas encore une version de production; déposer un bug avec eux.
Nex7

Réponses:

2

VOLSIZE représente la taille du volume telle qu'elle sera vue par les clients, et non la taille du volume telle qu'elle est stockée dans le pool.

Cette différence peut provenir de plusieurs sources:

  • espace requis pour les métadonnées
  • espace requis pour stocker plusieurs copies (les paramètres "copies")
  • "espace perdu" en raison du remplissage lors de l'alignement des blocs de taille "volblocksize" sur la structure vdev; par structure vdev, j'entends deux paramètres: le nombre de disques dans raidz-N et la taille des blocs physiques des périphériques.

Lors de la création d'un volume, zfs estimera l'espace dont il aurait besoin pour pouvoir présenter un volume de "volsize" à ses clients. Vous pouvez voir cette différence dans les volumes vtest-16 et vtest-3 (où la refreservation est de 102 Go et la taille du vol est de 100 Go). Le calcul peut être trouvé dans libzfs_dataset.c (zvol_volsize_to_reservation (uint64_t volsize, nvlist_t * props))

Ce qui n'est pas pris en compte par ce calcul est la troisième source. La troisième source a peu d'impact sur les vdev créés avec des disques ayant des secteurs de 512 octets. D'après mes expériences (j'ai testé qu'en remplissant un zvol entier pour le vérifier), cela fait une grande différence lorsque le vdev est créé sur des disques de secteur 4K plus récents.

Une autre chose que j'ai trouvée dans mes expériences est que le fait d'avoir des miroirs ne montre pas de différences entre la refreservation calculée et ce qui finit par être utilisé.

Ce sont mes résultats lorsque j'utilise des lecteurs 4K avec des volumes qui ont la taille par défaut volblocks (8K). La première colonne représente le nombre de disques dans 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%

Voici mes résultats lors de l'utilisation de lecteurs de secteur de 512 octets et d'une taille de bloc par défaut de 8 Ko. La première colonne représente le nombre de disques dans 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%

Mes conclusions sont les suivantes:

  • N'utilisez pas de lecteurs 4K
  • Si vous avez vraiment besoin de les utiliser, créez le volume en utilisant volblocksize supérieur ou égal à 32K; L'impact sur les performances est négligeable et les frais généraux d'utilisation de l'espace sont négligeables (les blocs de plus grande taille nécessitent moins de remplissage pour s'aligner correctement).
  • Préférez des bandes de miroirs pour vos piscines; Cette disposition présente à la fois des avantages en termes de performances et moins de surprises liées à l'espace comme celle-ci.
  • L'estimation est clairement erronée pour les cas décrits ci-dessus, et c'est un bogue dans zfs.
Dan Vatca
la source
2
L'utilisation de lecteurs 4k dans un pool avec ashift=9est connue pour causer des problèmes. Ce n'est pas nouveau. La modification de la taille du bloc n'aligne pas non plus les disques. La bonne solution consiste à créer le pool avec ashift=12.
Chris S
ashift=12sur les lecteurs 4K ne résout pas cela; en fait, sur un zpool avec ashift=12, 5 pcs de disques 4K et un raidz, l'espace consommé est proche de celui mentionné ci-dessus, par exemple le volume 7T consomme 11T.
drookie
-1

Si je lis bien, vous avez en fait logicalreferenced87,6 Go de données sur le volume. Le nombre de 170 Go que vous regardez est la quantité d'espace physique que les données utilisent. Donc, si vous avez vos disques en miroir, je m'attendrais referencedà environ 2x logicalreferenced.

long cou
la source
Hmm, un autre FS sur le même pool a referenced 3.50Get logicalreferenced 3.00Gdonc le rapport 2x n'est pas cohérent parmi les FS sur le pool.
Alex
Et d'ailleurs, la piscine n'est raidz2pas un simple miroir
Alex
Oui, je viens de faire quelques tests rapides sur une machine virtuelle et ma théorie n'a pas résisté.
longneck