从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 sendstream真的可能比它所用的池大几倍？
在Linux 0.6.1上观察到Z / ZFS。
正如tegbains在评论中指出的那样， zfs sendstream不会从任何存储级重复数据删除中受益。 他们也不受益于其他任何设置; 这就是zfs send | zfs receive zfs send | zfs receive可用于将数据迁移到新的设置，否则这些设置只有在数据被重写后才会生效 – 例如启用或禁用重复数据删除或更改压缩algorithm。
这是你的zfs发送数据stream比分配的存储空间大得多的主要原因。 在重复数据删除的特定情况下，除了最不可思议的原则（如果您需要的话）之外， 可能的原因是重复数据删除（ 特别是在ZFS中）代价非常高，并且决定zfs发送数据stream应该可以在较低特定的系统。
您的数据显示分配的2.36 TB，整体重复数据删除率为2.87x。 将这两个数字相加得到6.77TB，与估计的6.50TB接近，是一个合理的数字。 值得注意的是，6.50TB的数字与文件系统中的快照相关，而2.36TB * 2.87的数字与整个池相关。
如果你的ZFS实现支持这个选项，你可能会有一些运气与zfs send -D （生成重复数据删除zfs发送stream）。
在Linux 0.6.1上观察到Z / ZFS。
没有直接关系到你的问题，但我会build议升级。 截至撰写本文时（2015年6月），ZoL稳定在0.6.4.1，自2013年3月0.6.1出现以来，ZoL的增长和修复已经有了很多。