ZFS на Linux сжатие и порядок дедупликации

Question

Каков порядок записи данных в файловую систему zfs в zfs в linux?

Единственный конкретный документ, который я нашел на http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html, говорит; When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.

но если это так, то дедупликация не будет дедуплировать блоки, сжатые различными алгоритмами сжатия.

Я протестировал mysqlf и считаю, что порядок следующий: dedup, compress, encrypt .

Мой тест-сеттинг:

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

Вывод 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

создать случайный файл с помощью 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

Вывод списка zpool в пустой пул:

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

Затем скопируйте файлы в наборы данных с различными алгоритмами сжатия:

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

Вывод zfs list после копирования:

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

Вывод zpool list копирования:

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

Коэффициент дедупликации равен 2,0 после копирования одного и того же файла в разные наборы данных. На мой взгляд, это означает, что дедупликация выполняется для блоков данных перед сжатием и шифрованием.

Пожалуйста, кто-нибудь может проверить, правильно ли это?

Answer 1

Получается, что http://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.html прав.

Когда файл записывается, данные сжимаются, шифруются, и контрольная сумма проверяется. Затем данные дедуплицируются, если это возможно.

Мое предположение о случайном файле было неверным. Похоже, что ZFS прерывает сжатие, если не может достичь определенной минимальной степени сжатия.

цитата из https://wiki.illumos.org/display/illumos/LZ4+Compression

Следует особо отметить, что производительность LZ4 на несжимаемых данных очень высока. Это достигается путем включения механизма "раннего прерывания", который срабатывает, если LZ4 не может соответствовать ожидаемой минимальной степени сжатия (12,5% в ZFS).

Для тестирования я создал текстовый файл из моей файловой системы с помощью find / >> tree.txt .

После копирования файла в оба набора данных, а затем zpool get dedupratio вернул:

NAME  PROPERTY    VALUE  SOURCE
tank  dedupratio  1.00x  -

Dedup действительно последняя часть в этой цепочке записи. Выбор разных алгоритмов сжатия приведет к плохой дедупрации!

К сожалению, моя ZoL-версия не поддерживает шифрование. Но кажется, что шифрование разных наборов данных также может испортить дедупликацию. Информация о шифровании: https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html