任何人都可以澄清rsync的--checksum--ignore-times选项之间的区别吗?

我的理解如下:

--checksum
如果文件大小和时间匹配,它将在两端进行校验和,以查看文件是否真的相同。

--ignore-times <'传送'每个文件,而不管两端的文件时间是否相同。由于它仍将使用增量传输算法,因此,如果文件实际上相同,则不会传输任何内容。

这是技术上的区别,但据我所知,它们在语义上是相同的。

所以,我想知道的是:


两个选项之间的实际区别是什么?
在什么情况下您会使用一个而不是其他?
它们之间是否有性能差异?


#1 楼

通常,当文件在源端和目标端具有相同的大小和时间时,rsync会跳过文件。这是一种启发式方法,通常是一个好主意,因为它避免了rsync不得不检查源和目标端上很可能相同的文件的内容。

--ignore-times告诉rsync关闭文件时间和大小的试探法,因此无条件地将所有文件从源传输到目标。然后,由于是否需要使用rsync选项,--whole-file将继续读取源端的每个文件,因为它将需要使用其增量传输算法,或者只是完整发送每个文件。

--checksum还修改了文件时间和大小的试探法,但是在这里它忽略了时间,只检查大小。由于大小明显不同,因此会传输源和目标端大小不同的文件。对具有相同大小的文件进行校验和(在rsync 3.0.0+版中使用MD5,在较早版本中使用MD4),并且发现具有不同总和的文件也将被传输。

与目标端几乎相同,--checksum将导致大多数文件都被校验和。这可能会花费很长时间,但是最终结果是,最少量的数据实际上将通过电线传输,尤其是在使用增量传输算法的情况下。当然,只有在网络速度很慢和/或CPU速度非常快的情况下,这才是胜利。另一方面,--ignore-times将通过网络发送更多数据,这将导致要读取的源文件,但至少不会在源CPU和目标CPU上增加计算许多具有加密强度的哈希值的额外负担。当您的网络速度快和/或您的CPU相对较慢时,我希望此选项的性能比--checksum好。

我想如果将文件传输到怀疑某些文件的内容已损坏但修改时间未更改的目标位置,则只会使用--checksum--ignore-times。尽管可能还有其他用例,但我真的没有想到使用任何一个其他好的理由。

评论


我发现--checksum和--itemize-changes一起对验证备份很有用。当前每日/每周更新完成后,我的备份脚本会不时地以这种方式运行完整比较。如果--itemize-changes输出任何意外内容,我会收到一封标记为紧急的电子邮件,因此我知道我应该调查潜在的问题。

– David Spillett
2012年9月4日在9:58

--checksum在Git中工作并在具有更改文件的分支之间切换时非常有用,这会不断更改您不打算从特定分支发送的文件的更新时间。

–FriendlyDev
2015年4月20日在10:26



如果您的“文件”之一是Truecrypt文件容器,则--ignore-times尤其是--checksum是必需的,因为默认情况下不会更新文件的时间戳。请参阅productforums.google.com/forum/#!topic/drive/gnmDp3UXEgs和ask-leo.com/why_wont_my_truecrypt_volume_backup.html

– Marcus Junius Brutus
16年11月12日在21:47

注意:我做了一个快速实验,没有比较ctime,只有mtime。至少在Mac上。了解这一点可能很有用。这就是为什么Windows文件系统存在很多问题的原因,这些文件报告atime,mtime和ctime的同一时间(ctime)。

–爱德华·福克
17年1月10日在21:57



@DavidSpillett---checksum和--itemsize-changes在验证备份方面效果如何?例如,这些标志是否验证数据是否由于坏扇区或写故障而被破坏?

–有动力
20年1月3日,18:36

#2 楼

如果您使用的是另一个系统来同步文件(未保留时间戳),则校验和也很有用。校验和将仅传输不同的文件,并更新接收端的所有时间戳,以便它们匹配

评论


如果不提供--checksum标志,是否也不会这样做?

–lucidbrot
20年1月26日在18:22

是的,它将更新时间戳,但也可能传输许多不必要的文件。如果您在另一端运行rsync守护程序,并且连接速度很慢,并且文件很多(多演出源树),则校验和很有用。

– Paulus
20 Jan 27 '13:14

谢谢!请问另一个问题:如果我的每个源文件都大于1GiB并且连接速度中等,并且某些较新的时间戳仍然完全相同,那么您会怎么建议? -c将计算所有校验和(对吗?)-理想情况下,它仅计算时间戳不同的文件的校验和。还是以普通模式(不带-c标志)对这些文件进行校验和检查?

–lucidbrot
20 Jan 27 '20在16:34

#3 楼

一个细节:checksum选项在一端检查整个文件,然后在另一端检查整个文件。如果您的文件太大,则这种方式会杀死并行性。

此外,如果文件很大,则--checksum可能会超时,而-I则不然。

#4 楼

info rsync--checksum选项-“由于除了在文件传输期间进行自动校验和验证外,还对连接两侧的所有文件进行了整个文件校验和,因此此选项可能会很慢。” />

评论


该句子似乎不在我的手册页中……因此,这是否意味着checksum选项将使用校验和来识别文件是否相同,如果不相同,它将传输,从而再次生成校验和,如下所示:转让的一部分? --ignore-times选项仅跳过检查并假定它们已更改?因此,明智的--ignore-times是实现同一目标的更好方法吗?我仍在努力查看为什么有2个不同的选项(除了--checksum更加透明的事实)

–安迪·麦奇(Andy Madge)
2010-12-9 22:05

您应该查看最新的文档编辑:gitweb.samba.org/…

–亚历山大·列夫丘克(Aleksandr Levchuk)
2010-12-9 23:02

#5 楼

--ignore-times选项可能会导致所有文件进行增量编码,并且增量传输算法(增量编码)至少与校验和一样慢。

我不知道rsync --ignore-times是否足够聪明,可以避免在增量传输导致什么都没有传输的情况下进行“自动传输后验证”。 >
对于--ignore-times


如果rsync不明智(或不信任增量编码),则将进行两次检查(校验和和编码)。
也可能是增量编码比128位MD4校验和慢得多的情况。

--checksum--ignore-times都将“相当慢”,但--ignore-times可能甚至更慢(由于上面有2种可能性。)

好问题-如果您发现实践中存在任何性能差异,请发表。

评论


我明白你的意思了。我将运行一些测试并发回。

–安迪·麦奇(Andy Madge)
2010-12-9 22:57