Qual é a ordem dos dados gravados em um sistema de arquivos zfs no zfs no linux?
O único documento específico que encontrei emhttp://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.htmldiz;When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.
mas se isso fosse verdade, a desduplicação não desduplicaria os blocos compactados com diferentes algoritmos de compactação.
Testei o mysqlf e acredito que a ordem seja a seguinte: dedup, compress, encrypt.
Minha configuração de teste:
zpool create tank /dev/sdb
zfs create tank/lz4
zfs create tank/gzip9
zfs set compression=lz4 tank/lz4
zfs set compression=gzip-9 tank/gzip9
zfs set dedup=on tank
Saída dezfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 106K 19,3G 19K /tank
tank/gzip9 19K 19,3G 19K /tank/gzip9
tank/lz4 19K 19,3G 19K /tank/lz4
gerar um arquivo aleatório comdd if=/dev/urandom of=random.txt count=128K bs=1024
131072+0 Datensätze ein
131072+0 Datensätze aus
134217728 Bytes (134 MB) kopiert, 12,8786 s, 10,4 MB/s
Saída da lista zpool no pool vazio:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 134K 19,9G - 0% 0% 1.00x ONLINE -
Em seguida, copie os arquivos para os conjuntos de dados com diferentes algoritmos de compactação:
cp random.txt /tank/lz4
cp random.txt /tank/gzip9
Saída zfs listapós a cópia:
NAME USED AVAIL REFER MOUNTPOINT
tank 257M 19,1G 19K /tank
tank/gzip9 128M 19,1G 128M /tank/gzip9
tank/lz4 128M 19,1G 128M /tank/lz4
Saída da zpool listcópia posterior:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 129M 19,7G - 0% 0% 2.00x ONLINE -
A taxa de desduplicação é2,0depois de copiar o mesmo arquivo para conjuntos de dados diferentes. Na minha opinião, isso significa que a desduplicação é feita emdados-blocos antes da compactação e criptografia.
Por favor, alguém poderia verificar se isso está correto?
Responder1
Acontece quehttp://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.htmlestá certo.
Quando um arquivo é gravado, os dados são compactados, criptografados e a soma de verificação é verificada. Em seguida, os dados são desduplicados, se possível.
Minha suposição com o arquivo aleatório estava incorreta. Parece que o ZFS aborta a compactação se não conseguir atingir uma determinada taxa de compactação mínima.
Citação dohttps://wiki.illumos.org/display/illumos/LZ4+Compression
Outra coisa a notar é que o desempenho do LZ4 em dados incompressíveis é muito alto. Ele consegue isso incorporando um mecanismo de “aborto antecipado” que será acionado se o LZ4 não conseguir atender à taxa de compactação mínima esperada (12,5% no ZFS).
Para testar, criei um arquivo de texto do meu sistema de arquivos com find / >> tree.txt.
Depois de copiar o arquivo para ambos os conjuntos de dados e zpool get dedupratioretornar:
NAME PROPERTY VALUE SOURCE
tank dedupratio 1.00x -
A desduplicação é realmente a última parte desta cadeia de gravação. A escolha de diferentes algoritmos de compactação resultará em uma desdupração ruim!
Infelizmente, minha versão ZoL não suporta criptografia. Mas parece que criptografar diferentes conjuntos de dados também pode arruinar a desduplicação. Informações sobre criptografia:https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html