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

каков порядок записи данных в файловую систему 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 afer копирование:

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

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

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

5
задан Martin Seitl
30.03.2023 6:55 Количество просмотров материала 3373
Распечатать страницу

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  -

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

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

1
отвечен Martin Seitl 2023-03-31 14:43

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх