extraño informe de uso de espacio en disco ZFS para un ZVOL

8

Tenemos un ZVOL de 100G en un host FreeBSD 10.0-CURRENT que dice utilizar 176G de espacio en 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:~ #

Esto parece un error, ¿cómo puede consumir más de lo que es volsizesi no tiene instantáneas, reservas e hijos? ¿O tal vez nos estamos perdiendo algo?

Upd:

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

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

Resultados 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:

Creamos una serie de ZVOL con diferentes parámetros y los usamos ddpara mover el contenido. Notamos otra cosa extraña, el uso del disco era normal para ZVOL con 16k y 128k volblocksizey seguía siendo anormal para un ZVOL con 8k volblocksizeincluso después dd(por lo que este no es un problema de fragmentación):

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

y

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
fuente
Sospechamos que esto puede ser fragmentación, pero no sabemos cómo probarlo
Alex
¿Podría estar relacionado con las instantáneas?
Steve Wills
No, no tenemos instantáneas en este volumen
Alex
Triste cuando veo la compresión deshabilitada en los volúmenes / sistemas de archivos ZFS. De todos modos, ¿puedes publicar zpool status -vy zpool listy zfs list?
ewwhite
1
Por todo lo que puedo ver en esto, parece un error. El "uso" de un zvol con un volumen de 100G no debe exceder mucho más de 100G si no hay niños o reservas o similares. ¿Quizás fue en realidad un volumen de más de 200 GB y cambiaste el parámetro de tamaño? Si no, FreeBSD-10.0 aún no es una versión de producción; presentar un error con ellos.
Nex7

Respuestas:

2

VOLSIZE representa el tamaño del volumen tal como lo verán los clientes, no el tamaño del volumen almacenado en el grupo.

Esta diferencia puede provenir de múltiples fuentes:

  • espacio requerido para metadatos
  • espacio requerido para almacenar múltiples copias (los parámetros de "copias")
  • "espacio desperdiciado" debido al relleno al alinear bloques de tamaño "volblocksize" con la estructura vdev; por estructura vdev me refiero a dos parámetros: número de discos en raidz-N y tamaño de bloque físico de los dispositivos.

Al crear un volumen, zfs estimará cuánto espacio necesitaría utilizar para poder presentar un volumen de "volsize" a sus clientes. Puede ver esa diferencia en los volúmenes vtest-16 y vtest-3 (donde la actualización es de 102 GB y el volumen es de 100 GB). El cálculo se puede encontrar en libzfs_dataset.c (zvol_volsize_to_reservation (uint64_t volsize, nvlist_t * props))

Lo que no se tiene en cuenta en ese cálculo es la tercera fuente. La tercera fuente tiene poco impacto en vdevs que se crean con discos que tienen sectores de 512 bytes. A partir de mis experimentos (lo he probado completando un zvol completo para verificarlo), hace una gran diferencia cuando se crea el vdev sobre discos de sector 4K más nuevos.

Otra cosa que encontré en mis experimentos es que tener espejos no muestra diferencias entre la actualización calculada y lo que termina siendo utilizado.

Estos son mis resultados cuando uso unidades 4K con volúmenes que tienen el tamaño de volblocks predeterminado (8K). La primera columna representa el número de discos en 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%

Estos son mis resultados cuando uso unidades de sector de 512 bytes y un tamaño de volblocks predeterminado de 8K. La primera columna representa el número de discos en 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%

Mis conclusiones son las siguientes:

  • No use unidades 4K
  • Si realmente necesita usarlos, cree el volumen usando volblocksize mayor o igual a 32K; Hay un impacto insignificante en el rendimiento y una sobrecarga de uso de espacio insignificante (los tamaños de bloque más grandes requieren menos relleno para alinearse correctamente).
  • Prefiere rayas de espejos para tus piscinas; Este diseño tiene beneficios de rendimiento y menos sorpresas relacionadas con el espacio como este.
  • La estimación es claramente incorrecta para los casos descritos anteriormente, y este es un error en zfs.
Dan Vatca
fuente
2
ashift=9Se sabe que el uso de unidades 4k en un grupo causa problemas. Esto no es nada nuevo. Cambiar el tamaño del bloque tampoco alinea las unidades. La solución correcta es crear el grupo con ashift=12.
Chris S
ashift=12en unidades 4K no resuelve esto; de hecho, en un zpool con ashift=125 unidades de unidades 4K y un raidz, el espacio consumido es cercano al mencionado anteriormente, por ejemplo, el volumen 7T consume 11T.
drookie
-1

Si estoy leyendo esto correctamente, en realidad tienes logicalreferenced87,6 GB de datos en el volumen. El número de 170 GB que está viendo es la cantidad de espacio físico que utilizan los datos. Entonces, si tiene sus unidades duplicadas, esperaría referencedser aproximadamente 2x logicalreferenced.

cuello largo
fuente
Hmm, tiene otro FS en el mismo grupo referenced 3.50Gy, logicalreferenced 3.00Gpor lo tanto, la relación 2x ​​no es consistente entre los FS en el grupo.
Alex
Y, por cierto, la piscina raidz2no es un espejo simple
Alex
Sí, acabo de hacer algunas pruebas rápidas en una máquina virtual y mi teoría no se mantuvo.
cuello largo