我在server1上有一个数据集，我要备份到第二个server2。
Server1（原创）：
zfs list -o name,used,avail,refer,creation,usedds,usedsnap,origin,compression,compressratio,refcompressratio,mounted,atime,lused storage/iscsi/webhost-old产生：
NAME USED AVAIL REFER CREATION USEDDS USEDSNAP ORIGIN COMPRESS RATIO REFRATIO MOUNTED ATIME LUSED
storage/iscsi/webhost-old 67,8G 1,87T 67,8G Út kvě 31 6:54 2016 67,8G 16K - lz4 1.00x 1.00x - - 67,4G
向第二台服务器发送音量：
zfs send storage/iscsi/webhost-old | pv | ssh -c arcfour,aes128-gcm@openssh.com root@10.0.0.2 zfs receive -Fduv pool/bkp-storage
在378秒（189MB /秒）内收到69,6GB流
Server2 zfs list生成：
NAME USED AVAIL REFER CREATION USEDDS USEDSNAP ORIGIN COMPRESS RATIO REFRATIO MOUNTED ATIME LUSED
pool/bkp-storage/iscsi/webhost-old 36,1G 3,01T 36,1G Pá pro 29 10:25 2017 36,1G 0 - lz4 1.15x 1.15x - - 28,4G
为什么尺寸会有这么大差异？谢谢。
答案 0 :(得分：2)
根据你发布的内容，我发现有三件看似奇怪的事情：
compressratio在系统2上为1.15x，在系统1上为1.00x used比logicalused logicalused和数量zfs receive报告比系统2高出约2.3倍这些术语都在man page中定义，但在实践中仍然难以对逆向工程进行解释。
如果在将所有数据写入源数据集后对源数据集启用了压缩，则可能会发生（1），因为在启用该设置时，ZFS不会重写数据以对其进行压缩。zfs send发送的数据是未压缩的，除非您使用-c，但如果在目标数据集上启用了设置，则系统2会在运行zfs receive时尝试压缩它。如果系统1和系统2在写入数据之前都具有相同的压缩设置，那么它们也会具有相同的compressratio。
（2）可能由于与您的数据一起写入元数据而发生，但在这种情况下，它对于“普通”元数据来说太高了，“正常”元数据占大多数池的1-2％。它可能是由池范围的设置引起的，比如配置RAID-Z，或条带化和镜像的奇怪组合（如4条纹，但其中一条是镜像）。
对于（3），我重新阅读了手册页以试图解决它：
logicalused
The amount of space that is "logically" consumed by this dataset and
all its descendents. See the used property. The logical space
ignores the effect of the compression and copies properties, giving a
quantity closer to the amount of data that applications see.
如果您要发送数据集（而不是单个iSCSI卷）并且发送大小与系统2的logicalused值匹配（而不是系统1），我猜您忘记发送一些子数据集（即使用zfs send -R）。但是，在这种情况下，这些都不是真的。
我不得不做一些额外的挖掘 - this blog post from 2005可能包含解释。如果系统1在写入数据时没有启用压缩（就像我在上面针对（1）所猜测的那样），那么负责不写入清零块（zio_compress_data）的函数就不会被运行，所以你可能将一堆空块写入磁盘，并以logicalused大小计算。但是，由于lz4在系统2上配置，它将在那里运行，并且不会计算这些块。