zfs na compactação do Linux e na ordem de desduplicação

Question

Qual é a ordem dos dados gravados em um sistema de arquivos zfs no zfs no linux?

O único documento específico que encontrei no link diz; 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 for verdade, a dedup não deduzirá os blocos compactados com diferentes algoritmos de compactação.

Eu testei o mysqlf e acredito que a ordem é 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 de zfs 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

gere um arquivo aleatório com dd 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 de zpool no conjunto vazio:

NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  19,9G   134K  19,9G         -     0%     0%  1.00x  ONLINE  -

Copie os arquivos para os conjuntos de dados com diferentes algos de compactação:

 cp random.txt /tank/lz4
 cp random.txt /tank/gzip9

Saída de zfs list apó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 de zpool list afer copying:

NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  19,9G   129M  19,7G         -     0%     0%  2.00x  ONLINE  -

O índice de deduplicação é 2.0 depois de copiar o mesmo arquivo para diferentes conjuntos de dados. Na minha opinião, isso significa que a dedução é feita em dados -blocks antes da compactação e da criptografia.

Por favor, alguém poderia verificar se isso está correto?

    

Answer 1

Acontece que o link está correto.

When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.

Minha suposição com o arquivo aleatório estava incorreta. Parece que o ZFS anula a compactação se não puder atingir uma determinada taxa de compactação mínima.

citação de link

Another particular thing to note is that LZ4's performance on incompressible data is very high. It achieves this by incorporating an "early abort" mechanism which will trigger if LZ4 can't meet the expected minimum compression ratio (12.5% on ZFS).

Para testar, criei um arquivo de texto do meu sistema de arquivos com find / >> tree.txt .

Após copiar o arquivo para os dois conjuntos de dados e, em seguida, zpool get dedupratio retornou:

NAME  PROPERTY    VALUE  SOURCE
tank  dedupratio  1.00x  -

O Dedup é realmente a última parte desta cadeia de escrita. A escolha de algoritmos de compressão diferentes resultará em dedupratio deficiente!

Infelizmente, minha versão ZoL não suporta criptografia. Mas parece que a criptografia de conjuntos de dados diferentes também pode arruinar a dedução. Informações sobre criptografia: link