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

2284
Martin Seitl

Каков порядок записи данных в файловую систему 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 после копирования одного и того же файла в разные наборы данных. На мой взгляд, это означает, что дедупликация выполняется для блоков данных перед сжатием и шифрованием.

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

4

1 ответ на вопрос

1
Martin Seitl

Получается, что 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

Похожие вопросы