Каков порядок записи данных в файловую систему 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после копирования одного и того же файла в разные наборы данных. По моему мнению, это означает, что дедупликация выполняется наданные-блоки перед сжатием и шифрованием.
Пожалуйста, кто-нибудь может проверить, верно ли это?
решение1
Оказывается, чтоhttp://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.htmlверно.
При записи файла данные сжимаются, шифруются, проверяется контрольная сумма. Затем данные дедуплицируются, если это возможно.
Мое предположение о случайном файле было неверным. Похоже, что ZFS прерывает сжатие, если не может достичь определенного минимального коэффициента сжатия.
цитата изhttps://wiki.illumos.org/display/illumos/LZ4+Сжатие
Еще одна важная вещь, которую следует отметить, заключается в том, что производительность LZ4 на несжимаемых данных очень высока. Это достигается за счет включения механизма «раннего прерывания», который срабатывает, если LZ4 не может достичь ожидаемого минимального коэффициента сжатия (12,5% на ZFS).
Для тестирования я создал текстовый файл из своей файловой системы с расширением find / >> tree.txt.
После копирования файла в оба набора данных и последующего zpool get dedupratioвозврата:
NAME PROPERTY VALUE SOURCE
tank dedupratio 1.00x -
Дедупликация — это действительно последняя часть в этой цепочке записи. Выбор других алгоритмов сжатия приведет к плохой дедупликации!
К сожалению, моя ZoL-версия не поддерживает шифрование. Но, похоже, шифрование разных наборов данных также может испортить дедупликацию. Информация о шифровании:https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html