每天晚上我都会使用 rsync 将多个虚拟磁盘从一台 Linux Debian 计算机复制到另一台 Linux Debian。
大多数文件都是带有“漏洞”的原始映像：有些部分从未写入，因此在磁盘上仍未分配。
rsync 总是在一个文件上挂起。每次传输 50 Gb 后都会挂起。我不确定这是否总是在完全相同的位置，但ls -sh显示 50 Gb。
这是一个 800 Gb 的文件，包含 151 Gb（因此 649 Gb 未分配）。其他一些虚拟磁盘也有类似的数字，rsync 在它们上运行良好。
如果我使用 rsync 在本地更新文件，而不需要任何网络参与，则会出现完全相同的行为（--no-whole-file这是必需的，请参阅后面的内容）。
一旦 rsync 停滞，它会在接收端使用一个 CPU 核心达到 100% 且磁盘活动为零（这是一个拉取请求，因此 rsync 从这一端运行），在发送端则使用零 CPU 和零磁盘。
我让它运行了几个小时。
Ctrl+c立即停止 rsync。
当运行以进行本地复制时，一旦停滞，我也会让一个 CPU 核心达到 100% 且磁盘活动为零。
我发现的唯一例外是当我将此文件 rsync 到新位置时（即目标文件不存在）。所以我怀疑问题与新旧数据的比较有关。
我用--inplace它来限制对目标磁盘的写入，因为每次备份后都会使用快照。因此，此选项是必需的，rsync 也是如此，除非我找到了一种能够仅更新这些文件已更改部分的工具。
答案1
众所周知，rsync 在处理大文件时会出现此类问题，因为内部哈希缓冲区的算法效率低下。
您必须使用--block-size具有较大值的选项。但当前版本不允许使用超过 128 kB。有些网页会提示使用，--block-size=10485760 --protocol=29但在我的例子中，rsync 拒绝了。
- 使用 29 或更早版本
- 或者修改 MAX_BLOCK_SIZE 常量后重新编译
答案2
查看针对 rsync 的错误报告。也许可以提交一份新报告。您可以从以下位置找到这些报告https://rsync.samba.org/bugzilla.html
无论是在这里还是在错误报告中，您都应该提供更多细节。两端的 rsync 版本是什么、您的操作系统是什么、您使用的命令到底是什么？文件和/或 rsync 传输是否经过压缩？使用哪个 zlib 版本？
https://bugzilla.samba.org/show_bug.cgi?id=10518有可能https://bugzilla.samba.org/show_bug.cgi?id=10372可能相关。另请参阅http://www.anchor.com.au/blog/2013/08/out-tridging-tridge/