rsync存在各种性能问题；我从来没能让它执行同步O(#changes)。即使它使用修改时间而不是校验和，它仍然需要生成所有更改文件的列表，这可能需要几个小时或遇到一些任意限制。然而，这显然是可能的，例如使用写时复制文件系统，您可以立即传输“最小”差异，而无需重新扫描硬盘驱动器的几分钟（或几小时）的开销。
当然，使用以下算法是可能的：
my-ideal-rsync --modified-since "2020-10-10 12:00:00"将通过递归查看每个文件夹，并检查文件夹的上次修改时间（如果自该时间以来已被修改），以最佳 O（# 个已修改文件）时间而不是 O（磁盘上的# 个文件）时间列出/发送/流式传输修改的文件给定命令中的最后一次传输或者，
my-ideal-rsync2可以在没有上述标志的情况下通过以锁步方式递归比较每个系统的文件夹来实现：从根开始递归，将所有子 inode 对齐成对（源，目标）：
- 如果源 inode 具有相同的上次修改时间，则不递归
- 如果源 inode 有较新的上次修改时间，则递归（如果是目录）（或者发送（如果是文件）
- 如果源 inode 的上次修改时间较旧，则抛出错误
- 如果源或目标 inode 丢失，则将其排队以进行可能的
mv操作，即可能匹配的队列
- （如果递归结束时未找到匹配项，则分别执行删除或创建）
也许上面的算法有一个错误，但它说明了这个概念。有这样的事吗？
答案1
目录修改时间与文件修改时间无关。 – 罗艾玛 1 月 29 日 7:41
由于我对目录修改时间的误解（至少在 ext4 等上），在没有使用提供“子目录中的文件已更改”时间的文件系统的情况下，似乎这样的算法是不可能的。 （或者，将 fs 设置为只读，除非正在运行文件修改守护进程来跟踪稍后 rsync 的更改...呃。）
暂时回答这个问题，因为“这样的算法可能在普通文件系统中是不可撤销的，因为 dir mtimes 独立于文件 mtimes；只需使用btrfs send
答案2
rsync 程序不记录差异，所以它必须扫描整个目录树。
相反，git版本控制系统跟踪对文件和目录所做的修改并保留所有历史记录，因此这可能正是您所需要的。