relatório de uso de espaço em disco estranho do ZFS para um ZVOL

8

Temos um ZVOL 100G em um host FreeBSD 10.0-CURRENT que afirma usar 176G de espaço em 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:~ #

Isso parece um bug, como ele pode consumir mais do que o seu volsizese não tiver instantâneos, reservas e filhos? Ou talvez estejamos perdendo alguma coisa?

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

Atualização 2:

Criamos vários ZVOLs com parâmetros diferentes e usamos ddpara mover o conteúdo. Percebemos outra coisa estranha: o uso do disco era normal para ZVOLs com 16k e 128k volblocksizee permanecia anormal para um ZVOL com 8k volblocksizemesmo depois dd(portanto, esse não é um problema de fragmentação):

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
Nós suspeitamos que esta pode ser a fragmentação, mas não sabemos como provar isso
— Alex
Poderia estar relacionado a instantâneos?
— Steve Wills
Não, não temos nenhum instantâneo neste volume
— Alex
Triste quando vejo a compactação desativada nos volumes / sistemas de arquivos ZFS. De qualquer forma, você pode enviar zpool status -ve zpool liste zfs list?
— ewwhite
1
De tudo o que posso ver nisso, parece um bug. O 'usado' de um zvol com um volume de 100G não deve exceder muito os 100G anteriores, se não houver filhos, reservas ou algo parecido. Talvez fosse realmente um volume de mais de 200 GB e você alterou o parâmetro volsize? Caso contrário, o FreeBSD-10.0 ainda não é um lançamento de produção; registrar um bug com eles.
— Nex7 31/05

Respostas:

2

VOLSIZE representa esse tamanho do volume como será visto pelos clientes, não o tamanho do volume armazenado no pool.

Essa diferença pode vir de várias fontes:

  • espaço necessário para metadados
  • espaço necessário para armazenar várias cópias (os parâmetros "cópias")
  • "espaço desperdiçado" devido ao preenchimento ao alinhar blocos de tamanho "volblocksize" à estrutura vdev; por estrutura vdev, quero dizer dois parâmetros: número de discos em raidz-N e tamanho do bloco físico dos dispositivos.

Ao criar um volume, o zfs estimará quanto espaço precisaria usar para poder apresentar um volume de "volsize" a seus clientes. Você pode ver essa diferença nos volumes vtest-16 e vtest-3 (em que a atualização é de 102 GB e o tamanho do volume é de 100 GB). O cálculo pode ser encontrado em libzfs_dataset.c (zvol_volsize_to_reservation (uint64_t volsize, nvlist_t * props))

O que não é levado em consideração por esse cálculo é a terceira fonte. A terceira fonte tem pouco impacto nos vdevs criados com discos com setores de 512 bytes. Pelas minhas experiências (testei isso preenchendo um zvol inteiro para verificar isso), faz bastante diferença quando o vdev é criado em discos mais recentes do setor 4K.

Outra coisa que encontrei em meus experimentos é que ter espelhos não mostra diferenças entre a atualização calculada e o que acaba sendo usado.

Estes são os meus resultados ao usar unidades de 4K com volumes com o tamanho padrão de volblocks (8K). A primeira coluna representa o número de discos em um 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%

Estes são meus resultados ao usar unidades de setor de 512 bytes e tamanho padrão de 8K. A primeira coluna representa o número de discos em um 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%

Minhas conclusões são as seguintes:

  • Não use unidades 4K
  • Se você realmente precisar usá-los, crie o volume usando tamanho de bloco maior ou igual a 32K; Há impacto insignificante no desempenho e sobrecarga insignificante no uso de espaço (tamanhos de bloco maiores requerem menos preenchimento para se alinhar adequadamente).
  • Prefira faixas de espelhos para suas piscinas; Esse layout tem benefícios de desempenho e menos surpresas relacionadas ao espaço como este.
  • A estimativa está claramente errada para os casos descritos acima, e isso é um bug no zfs.
— Dan Vatca
fonte
2
O uso de unidades de 4k em um pool com ashift=9é conhecido por causar problemas. Isso não é novidade. Alterar o tamanho do bloco também não alinha as unidades. A solução correta é criar o pool com ashift=12.
— Chris S
ashift=12em unidades de 4K não resolve isso; de fato, em um zpool com ashift=125 unidades de unidades 4K e um RAIDZ, o espaço consumido é próximo ao mencionado acima, por exemplo, o volume de 7T consome 11T.
— drookie
-1

Se estou lendo isso direito, você realmente possui logicalreferenced87,6 GB de dados no volume. O número de 170 GB que você está vendo é quanto espaço físico esses dados usam. Portanto, se você tiver seus discos espelhados, eu esperaria referencedcerca de 2x logicalreferenced.

— pescoço longo
fonte
Hmm, outro FS no mesmo pool tem referenced 3.50Ge, logicalreferenced 3.00Gportanto, a proporção 2x não é consistente entre FSs no pool.
— 30513 Alex
E pela forma como a piscina é raidz2, não simples espelho
— Alex
Sim, eu fiz alguns testes rápidos em uma VM e minha teoria não se sustentou.
— longneck 30/05
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.