我需要使用 Rsync over SSH 将文件从多个服务器传输到单个远程主机。但是，我需要确保在使用 --remove-from-source 参数在源上删除文件之前，传输的文件确实存在。
从我读到的内容来看，没有传输后校验和，并且 rsync 信任内核响应，但这些文章的日期可以追溯到 2005-2009 年。我想知道最近的 rsync 更新中这是否有所改变？如果不是，有什么方法可以检查这一点，然后在验证后删除源文件？
编辑：我不明白这怎么是重复的。我的问题与同一系统上的本地驱动器无关......
答案1
概括：如果 rsync 将数据写入磁盘，它将无损地执行此操作。然而，为了完全确定实际上已将数据写入磁盘，您需要应用fsync.diff补丁，或者sync <files>稍后致电。
SSH提供数据的完整性—您收到的数据与您发送的数据相同。这就是网络的原因。
然后，rsync使用write系统调用，要求内核将数据写入磁盘。除非您的硬盘出现故障（另一个问题），否则这也可以保持数据完整性。
然而，确保数据现在实际上在磁盘上令人恼火的是，事情并没有那么简单。这write手册页做出以下说明：
write() 的成功返回并不能保证数据已提交到磁盘。事实上，在一些有缺陷的实现中，它甚至不能保证已成功为数据保留空间。唯一确定的方法是在写入所有数据后调用 fsync(2)。
我下载的最新的（3.1.2pre1）rsync 的源代码，greppedfsync并没有得到任何结果。默认情况下，rsync不调用fsync（我还查找了无元数据版本fdatasync：也没有）。这意味着这些writes 是否已经完成任何操作取决于文件系统。
作为解决方案，您可以：
Run
sync <files>，它调用fsync给定的文件。当它返回时，它们肯定在磁盘上。下载 rsync 源补丁目录（作为单独下载提供）。应用
fsync.diff萨米·法林 (Sami Farin) 制作的补丁。它“如果您希望在我们编写的每个文件上调用 fsync()，则可以指定 --fsync”。 （这有望在未来成为默认设置。）
通常虽然，现代文件系统很快就会完成您的写入，只是在 IO 负载较高时短暂地利用它们的自由度进行缓存。如果您了解自己的系统，则可以跳过此步骤。但请记住，在编写更广泛使用的代码时，结果可能会有所不同，具体取决于您的文件系统、它的调整方式以及驱动器上的固件上帝是否感到仁慈。