Из zfs send -R -v pool/fs@snap:
send from @ to pool/fs@snap estimated size is 6.50T
... но из zpool list:
NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT
pool 3.62T 2.36T 1.27T 65% 2.87x ONLINE -
Может ли zfs send поток действительно будет в несколько раз больше, чем пул из которого он взят?
Наблюдается с ZFS в Linux 0.6.1.
Так как Тегбайнс указал в комментарии, zfs send потоки не получают преимуществ от какой-либо дедупликации на уровне хранилища. Им также не нужны никакие другие настройки; вот почему zfs send | zfs receive могут использоваться для переноса данных в новые настройки, которые в противном случае вступили бы в силу только после перезаписи данных - например, включение или отключение дедупликации или изменение алгоритмов сжатия.
Это основная причина, по которой ваш поток отправки zfs становится намного больше, чем выделенное пространство для хранения. А скорее всего Причина этого в конкретном случае дедупликации, помимо принципа наименьшего удивления (если он вам нужен), заключается в том, что дедупликация (особенно в ZFS) очень дорого обходится, и было принято решение, что потоки отправки zfs должны быть доступны в системах с более низкими характеристиками.
По вашим данным, выделено около 2,36 ТБ, а общий коэффициент дедупликации составляет 2,87x. Умножая эти два числа, мы получаем 6,77 ТБ, что достаточно близко к расчетным 6,50 ТБ, чтобы считаться разумным приблизительным значением. Конечно, стоит отметить, что цифра 6,50 ТБ относится к моментальному снимку в файловой системе, а цифра 2,36 ТБ * 2,87 относится ко всему пулу.
Если ваша реализация ZFS поддерживает эту опцию, возможно, вам повезет с zfs send -D (сгенерировать дедуплицированный поток отправки zfs).
Наблюдается с ZFS в Linux 0.6.1.
Не имеет прямого отношения к вашему вопросу, но я бы предложил обновить его. Стабильный ZoL находится на уровне 0.6.4.1 на момент написания этой статьи (июнь 2015 г.), и с момента выхода версии 0.6.1 в марте 2013 г. было внесено множество улучшений и исправлений.