ZFS 2.1.0 draid send/recv в итоге пропало сжатие

М б баг send/recv для жатых пулов? send как делал(параметры)?

recv использует сжатие целевого пула/датасета.

Это не баг, а фича. И вполне обоснованная: диски разные, условия их использования тоже разные.

Настройки zfs на пуле аналогичные

он должен был пожать, а не жмет на приемнике 38 <> 76

он должен был пожать

Как были запущены zfs send/zfs recv?

На обоих серверах на пулах аналогичные настройки zfs/. Вот некоторые из них, которые могут повлиять на размер занимаемый файлами:

$ zfs get all pool

pool recordsize 64K local

pool compression zstd-1 local

pool copies 1 default

pool dedup off default

Разделы на пуле получали настроки по дефолту или наследовали (recordsize, compression).

root@backup:~# /usr/bin/ssh server /usr/sbin/zfs send -c pool/home@week | /usr/sbin/zfs recv -s pool/server/home

Он типа сжал 78МБ (на диске показал du -h) < 100МБ (размер файла). Но zfs get compressratio говорит, что среднее сжатие файлов примерно 2. И если в этот раздел скопировать этот же файл, то du -h покажет 39МБ. Т.е. файлы да сжимаются, но либо не так эффективно, как при прямом копировании, либо при send/recv делается какое-то ещё избыточное копирование. Как в случае со сжатым файлом, который занял 4,7ГБ при своём размере 3ГБ, а прямом копировании 3,5ГБ.

судя по ману

Generate a more compact stream by using compressed WRITE records for blocks which are compressed on disk and in memory (see the compression property for details). If the lz4_compress feature is active on the sending system, then the receiving system must have that feature enabled as well. If the large_blocks feature is enabled on the sending system but the -L option is not supplied in conjunction with -c, then the data will be decompressed before sending so it can be split into smaller block sizes.

я бы предположил, что send -c читает уже пожатые блоки, жмет их и отсылает. На другом конце пожатый поток расжимается и пишутся пожатые блоки и опять жмутся.

send без «-c» как себя поведет?

send: -Le -c -I

recv: -du

compressratio=2.02

-L имеет смысл если recordsize > 128KB

-e работает только со сжатием lz4

-I тащит все снэпшоты, которые были сделаны до запрошенного (и его естественно тоже). У меня создаются снэпшоты каждую полночь, но на бэкап сервер кидаю только один за неделю.

-d влияет только на имя раздела на бэкап сервере

-u не монтирует фс

На сжатие файлов и размер раздела может повлиять только -c

Сейчас гоняю send/recv с разными сочетаниями: версия zfs 2.0.5 и 2.1.0, с опцией -c и без неё. Результатами поделюсь.

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

zfs send -i …

Вы угадали! Именно так и делаю. :)

И там же сказано: Streams sent with -c will not have their data recompressed on the receiver side using -o compress= value. The data will stay compressed as it was from the sender. The new compression property will be set for future data.

Т.е. данные отсылаются в сжатом виде и остаются в том виде, как они на отправителе. А свойство сжатия заданное на принимающей стороне будет использовано для будущих данных.

Я всё это знаю. У меня бэкап делается именно так (хотя не везде lz4, да и не везде сжатие включено, но на пуле именно он выставлен на родительском датасете).

У меня на FreeBSD 13.0-RELEASE искаропки 2.0.0 коммит f11b09dec.

И вот результат тестирования.

Два одинаковых сервера, каждый с 12 дисками по 3ТБ, ОС Linux CentOS 8.4, zfs 2.1.0. На первом сервере пул собран - zpool create -o ashift=12 pool raidz sd[a-d] raidz sd[e-h] raidz sd[i-l] На втором собираем draid - zpool create -o ashift=12 pool draid:5d:12c sd[a-l] Настройки на пулах одинаковые - zfs set recordsize=64k compression=zstd-1 mountpoint=none readonly=on pool Первый сервер исходный, на нём тестовый раздел:

pool/test  compressratio  2.50x
pool/test  used           248G
pool/test  logicalused    503G

Качаем его с первого на второй с опцией -c и без неё - ssh server1 /usr/sbin/zfs send -c pool/test@b | /usr/sbin/zfs recv -s pool/testc и ssh server1 /usr/sbin/zfs send pool/test@b | /usr/sbin/zfs recv -s pool/test В обоих случаях получаем интересную картину:

pool/test  compressratio  1.82x
pool/test  used           390G
pool/test  logicalused    515G

Т.е. потери и в степени сжатия и в занятом объёме, да ещё дополнительно 12ГБ данных.

Если пересобрать на втором сервере пул так же как на первом, то при пересылке раздела (что с опцией -c что без неё) результат будет равен исходному. Т.е. ничего лишнего и сжатие нормальное. И да, опция -c действительно ускоряет пересылку раздела. В моём случае это примерно 2-2,5 раза. Таким образом видно, что вся причина в draid.

И ещё один камень в сторону draid. Рабочий бэкап сервер, для которого всё это и делалось. 16 дисков по 8ТБ. Собираем draid - zpool create -o ashift=12 pool draid:7d:16c sd[a-p] - получаем пул полезного объёма 93ТБ. Собираем аналог RAID-50 - zpool create -o ashift=12 pool raidz sd[a-h] raidz sd[i-p] - получаем пул на 98ТБ. Т.е. при использовании draid теряем ~5% полезного объёма.

Мой вывод. Для бэкап сервера, которого важен полезный объём пула, а не стабильность 24/7, draid не подходит.

Таким образом видно, что вся причина в draid.

об этом, в общем-то, прямым текстом написано в документации

Да, сказано If using compression, this relatively large allocation size can reduce the effective compression ratio. Небольшое ухудшение сжатия было видно, когда копировал файлы напрямую в draid. Но когда файл занимает в полтора раза больше своего размера - это уже слишком.

Ээм, разве не raid60 (zraid2) и draid похожие?

А, ну, да пардон, скорее raid50 + hot-swap

Всё зависит от настроек. Я делал как RAID-50 без hot-swap.