是什么使rsync的一侧如此繁忙？

我的局域网上有一台Debian机器，作为其他机器的备份服务器。它在LVM和btrfs上将四个HDD组合成一个软件RAID 5 md设备。备份是使用rsync进行的，大型文件系统需要一个多小时。很长时间以来，我一直认为我对此无能为力。

但是，最近，我注意到硬盘的活动在传输的两端都非常不同。尽管运行Gentoo并主要使用ext4的发送方几乎没有任何磁盘IO，但是接收方一直很忙。由于大多数数据在两次传输之间不会改变，因此我认为元数据读取应构成大部分数据。但是，如果在btrfs中读取inode而不是在ext4中进行如此大的工作，我会感到非常惊讶。

iotop 经确认，接收方的磁盘读取速度约为1-4 MB / s，而发送方偶尔只有0.5 MB / s的突发速度。

我的问题是，谁能解释这是怎么回事？最好带有一些指示，如果可能的话，如何解决该问题。

也许有一些我可以使用的btrfs调整标志，或者类似的东西。我需要备份服务器上具有快照功能的FS，而我尝试使用FreeBSD和ZFS会很快导致FS不一致，因此目前我看不到btrfs的替代方案。因此，告诉我使用ext4或zfs的答案可能会收到投票，但没有复选标记。

根据cjm的要求，正在使用Rsync选项：

--rsync-path='rsync --fake-super'
--archive               # -rlptgoD
--hard-links            # detect and preserve these
--acls
--xattrs
--sparse
--noatime               # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable        # size suffixes, base 1000
--stats

以及一堆-f删除某些文件的规则。

btrfs的安装选项报告mount为

rw,nosuid,noexec,noatime,nospace_cache

特别是，这包括noatime标志，因此除非某些文件中确实存在差异，否则不应该涉及任何写作。我响应添加了这个信息的答案由凯尔·琼斯。

— MV
source

您正在使用哪些rsync选项？

— cjm 2012年

只是在黑暗中拍摄，您的磁盘有故障吗？这可能会导致额外的I / O，因为它试图从奇偶校验信息中重建丢失的数据。

— bahamat

@bahamat，我已经很聪明了，它没有任何问题。mdadm均未报告任何事件。

— MvG 2012年

很难确定什么地方出了问题。仅一个示例是各层之间的块大小不匹配。为了对其进行诊断，最好的方法是使用类似的东西dtrace或systemtap找出花费时间的地方。

— bahamat 2012年

@bahamat，这是我尚未调查的途径。您能否写出有关如何使用这些工具诊断问题的答案？那太好了。如果有时间，请逐步进行说明，但是即使是一些粗略的想法和文档指导也将非常有帮助。

— MvG 2012年

一种可能的答案是，默认情况下使用“ atime”选项安装远程文件系统。访问时间会写入远程rsync所访问的所有内容，再加上您对RAID 5遭受的写入损失（计算奇偶校验意味着在写入其中任何一个RAID磁盘之前先读取所有RAID磁盘），就可以说明远程I / O放大率。

如果我是对的，则可以通过使用“ noatime”选项挂载远程文件系统来加快处理速度。

— 凯尔·琼斯（Kyle Jones）
source

好主意，但可惜不是解决方案：文件系统已经挂载了noatime。Mount将所有安装选项的集合报告为rw,nosuid,noexec,noatime,nospace_cache。

— MvG 2012年

我怀疑--fake-super选项。这告诉rsync将所有元数据信息存储在每个文件的扩展属性中。我怀疑访问这些属性的速度很慢。尝试使用rsync到没有--fake-super的根进行测试运行。由于属性不匹配，因此无法重复使用相同的备份。

— 韦恩
source

您应该考虑扩展您的答案，以包括一些有用的链接或对支持您的断言的文档的引用。

— HalosGhost