compression zfs sur linux et ordre de dédu

Quelle est la commande des données écrites sur un système de fichiers zfs sous zfs sous linux?

Le seul document spécifique que j'ai trouvé à http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html dit; When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.

mais si cela était vrai, alors dedup ne dédrammerait pas les blocs compressés avec des algorithmes de compression différents.

J'ai testé mysqlf et je crois que la commande est la suivante: dedup, compress, encrypt.

Mes paramètres de test:

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

Sortie 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

générer un fichier aléatoire avec 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

Sortie de la liste zpool sur un pool vide:

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

Copiez ensuite les fichiers dans les jeux de données avec différents algorithmes de compression:

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

Sortie de zfs list après avoir copié:

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

Sortie de zpool list après avoir copié:

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

Le rapport de déduplication est 2.0 après avoir copié le même fichier dans différents jeux de données. A mon avis, cela signifie que la déduplication est effectuée sur Les données -blocs avant la compression et le cryptage.

S'il vous plaît, quelqu'un pourrait-il vérifier si cela est correct?

Il se trouve que http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html est juste.

Lorsqu'un fichier est écrit, les données sont compressées, cryptées et la somme de contrôle est vérifiée. Ensuite, les données sont dédupliquées, si possible.

Mon hypothèse avec le fichier aléatoire était incorrecte. Il semble que ZFS abandonne la compression s'il ne peut pas atteindre un certain taux de compression minimum.

Citation de https://wiki.illumos.org/display/illumos/LZ4+Compression

Une autre chose à noter est que les performances de LZ4 sur des données incompressibles sont très élevées. Il y parvient en intégrant un mécanisme "d'abandon précoce" qui se déclenche si LZ4 ne peut pas respecter le taux de compression minimum prévu (12,5% sur ZFS).

Pour tester, j'ai créé un fichier texte à partir de mon système de fichiers avec find / >> tree.txt.

Après avoir copié le fichier dans les deux jeux de données, puis zpool get dedupratio est revenu:

NAME  PROPERTY    VALUE  SOURCE
tank  dedupratio  1.00x  -

Dedup est vraiment la dernière partie de cette chaîne d'écriture. Le choix de différents algorithmes de compression entraînera une dédupratio médiocre!

Malheureusement, ma version de ZoL ne prend pas en charge le cryptage. Mais il semble que le cryptage de différents jeux de données pourrait également ruiner la déduplication. Info sur le cryptage: https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html