Дедупликация на ZFS: есть истории успеха?

Это медленно.

Кто-нибудь эффективно использует дедупликацию ZFS?

Не думаю. Зато знаю и имею опыт эффективной дедубликации на обычном XFS с помощью rdfind. Сам понимаешь, что ZFS в такой схеме - лишняя деталь.

Использовал дедупликацию в юзкейсе ZFS+NFS+PXE, единственный случай когда оно действительно окупается.

• Так он же на этом скачке расколется, редиска, при первом же шухере (комментарий) (последний абзац)

• Так он же на этом скачке расколется, редиска, при первом же шухере (комментарий)

это безумно медленно и очень требовательно к объему ОЗУ

То, что медленно - ок. А что с уровнем дедупликации?

Использовал дедупликацию в юзкейсе ZFS+NFS+PXE, единственный случай когда оно действительно окупается.

Да, интересный кейс…

А что с уровнем дедупликации?

Очень зависит от данных. Если это много одинаковых данных, например, джейлы (или прочие контейнеры) или бэкапы (с повторяющейся структурой, например как у tar(1)) — выигрыш будет ощутимым, в остальных случаях только проиграешь, и чем больше данных будет в датасете, тем больше будет проигрыш. Именно по этой причине совершенно бессмысленно (а то и вообще вредно) включать дедупликацию на датасете с какой-нибудь мультимедией или играми.

За подробностями иди по ссылкам.

PXE

интересный кейс

Самый обычный. Обновлять ОС, раздаваемую по NFS, затея не очень, клоны не всегда решают (например разные релизы; а обновление на следующий релиз заставит разжиреть клон на объём релиза), но даже на разных релизах можно выиграть дедупликацией не меньше половины объёма одного из "контейнеров".

С джейлами/контейнерами можно нарулить thin provisioned с nullfs(5) (OverlayFS) сверху, что избавит от нужды иметь несколько копий одного релиза, а отсутствие проблем которые присутствуют с использованием сети позволяет жонглировать ими как угодно. В этом случае дедупликация нужна только когда есть "толстые" контейнеры или если разные потомки-клоны "пошли разными путями". Если контейнеров мало а их ротация достаточно частая, то дедупликация может пойти во вред.

У нас админы на пытались использовать. Очень медленно и очень небольшой выхлоп - отказались.

[code] NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT nextcloud 496G 179G 317G - - 15% 36% 1.25x ONLINE - [/code]

файлы - текст и pdf

Странный вопрос по уровню дедупликации, собственно.

Есть данные подверженные оной, есть нет.

Вот мой уровень:

# zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
tank  18.1T  16.1T  2.00T        -         -    41%    88%  4.52x    ONLINE  -

Мой уровень: 4,5 раза. И плюс ещё сжатие в полтора раза сжимает :) И так-как данные подобраны соответствующие, то и скорость норм. Юзаю для полных бекапов СУБД

1.25x

это просто трата ресурсов в никуда

Юзаю для полных бекапов СУБД

один из способов применения точно по цели, так сказать. в дедуп ящиках у некоторых конкурентов, типа data domain, rubrik, etc применяется variable block dedup и даже на incremental forever можно получить уровень дедупа 7-8х. а сжимать бэкапы может и база, причём, гораздо эффективнее.

а, да, зелёный кот передаёт превед с банановой республики.

Сжатые данные могут дедуплицироваться?

zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
new-pool 412G 134G 278G - - 5% 32% 1.02x ONLINE /

игры, бекап гугл диска, бекап корня

какой recordsize/volblocksize?

а какой должен быть, как его считать?

sudo zfs get all|grep -i size
new-pool recordsize 128K default
new-pool dnodesize legacy default
new-pool/backup recordsize 128K default
new-pool/backup dnodesize legacy default

какой объем данных?

винт 420 гб раздел, данных около 130 гб

в дедуп ящиках у некоторых конкурентов, типа data domain, rubrik, etc применяется variable block dedup

Вот интересно, в ZFS variable block deduplication запилят когда-нибудь?

Кстати, есть ли опыт использования variable block deduplication в в linux?

1.02x

Мало; хотя, конечно, это по пулу в целом…

Я правильно понимаю, что у тебя на:

игры, бекап гугл диска, бекап корня - включена дедупликация?

Смотря чем и как сжатые... На простых lz с маленькими словарями ещё может что-то быть, но кто так нынче жмёт? В общем случае, при наличии ещё и энтропийного кодирования, думаю, дедуп упадёт сильно.

Проверял ради прикола на образах виртуалок пожатых и на выгрузках dt - 1С. Дедуп: 0%.

да, на всё. тестирую.

Зря время тратишь :) Только одинаковые данные дедуплицируются, т.е. в общем случае, ну бекапы (и то, с оговоркой). Всё остальное, в общем то трата ресурсов в никуда.

Как и ожидалось. В dt-шках вроде lzma. Лучше хранить несжатые данные и попробовать поднять размер блока(вроде аж до 16МБ можно, тут и дедупу возможно полегче будет) и выставить сжатие на feature@zstd_compress повыше. Будет сжато конечно не так сильно, как на файловом уровне, но зато будут плюшки zfs.

Лучше

Цифры то где? Только слова «ни о чём»?

кстати, как узнать дедап у дочернего тома?
его он не показыват тут

кстати, как узнать дедап у дочернего тома?

Средствами zfs - никак, ибо дедупликация идёт на уровне пула, а не FS.

Можно примерно прикинуть, исходя из размера пула и FS, где включена дедупликация.

Юзаю для полных бекапов СУБД

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

Сильно под вопросом насчет цели. Вариант пролюбить н-цать бэкапов разом тоже надо рассматривать. Что с учетом того, что это субд, а не «файлопомойка» может оказаться весьма больно.
ЗЫ Пишу на волне того, что сейчас понадобилось развернуть последовательно несколько ежедневных бэкапов базы месячной давности.