ZFSの推定送信サイズは、合計データサイズよりもはるかに大きい
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ストリームは、それが取得されたプールよりも実際に数倍大きくなる可能性がありますか？
Linux0.6.1でZFSを使用して観察されました。
tegbains コメントで指摘されているように、zfs sendストリームは、ストレージレベルの重複排除の恩恵を受けません。また、他の設定の恩恵を受けることもありません。これが、zfs send | zfs receiveを使用して、データを新しい設定に移行できる理由です。新しい設定では、データが書き換えられた場合にのみ有効になります。たとえば、重複排除の有効化または無効化、圧縮アルゴリズムの変更などです。
これが、zfs送信ストリームが割り当てられたストレージスペースよりもはるかに大きくなる主な理由です。重複排除の特定のケースでの可能性の高い理由は、驚き最小の原則（必要な場合）を超えて、重複排除（特にin ZFS）は非常にコストがかかるため、zfs送信ストリームは仕様の低いシステムで受信可能である必要があると判断されました。
データは、約2.36 TB割り当てられ、全体的な重複排除率は2.87xです。これら2つの数値を単純に乗算すると、6.77 TBになり、推定6.50 TB妥当な球場の数値であるため、6.50 TBの数値はファイルシステムのスナップショットに関連し、2.36TB * 2.87の数値はプール全体に関連することは確かに注目に値します。
ZFS実装がそのオプションをサポートしている場合は、zfs send -D（重複排除されたzfs送信ストリームを生成する）で運が良かったかもしれません。
Linux0.6.1でZFSを使用して観察されました。
あなたの質問とは直接関係ありませんが、アップグレードすることをお勧めします。安定 ZoL この記事の執筆時点（2015年6月）では0.6.4.1であり、2013年3月に0.6.1がリリースされて以来、多くの機能強化と修正が行われています。