了解 rsync 的 --info=progress2 输出

muf*_*fel 117 rsync

如果我跑rsync--info=progress2,我得到这样的输出

105.45M  13%  602.83kB/s    0:02:50 (xfr#495, ir-chk=1020/3825)
Run Code Online (Sandbox Code Playgroud)

但是单个数字是什么意思?我在手册页中没有找到匹配的条目。

  • 第一个数字似乎是处理的数据量(实际复制的字节以及跳过的字节,因为它们已经存在于目标位置),对吗?这似乎不是传输数据的数量,因为它增加的速度比我的互联网连接速度快...
  • 百分比是指数据量还是要复制的文件数?它是否考虑排除的文件和在目标位置已经是最新的文件?
  • 排在第三位的时间似乎是完成时间的估计,但是当我尝试时,它在几小时到几秒之间跳跃。它指的是什么,它是如何计算的?
  • 最后两个数字是什么意思?

Yur*_*ira 149

105.45M 13% 602.83kB/s 0:02:50 (xfr#495, ir-chk=1020/3825)
Run Code Online (Sandbox Code Playgroud)

意思是:

  • 到目前为止,接收方/目的地已经重建了大约 811.15 兆字节 (100%) 的发送方/源文件中的105.45 兆字节(或13% )。
  • 这些文件以每秒602.83 KB的速度重建,到目前为止,此数据传输操作耗时2 分 50 秒(已用时间)。

此外,xfr#495表示当前正在传输第 495 个文件,而ir-chk=1020/3825表示,在(到目前为止)递归扫描(检测到)的总共3825 个文件中,到目前为止,其中1020个文件仍在传输进行检查/验证。

这意味着如果扫描检测到例如更多 100 个要检查的文件,则双方将增加 100(然后读取ir-chk=1120/3925)。扫描完所有文件后(增量递归扫描检测到),斜线右侧的数字将保持不变,直到整个过程结束,而斜线左侧的数字将开始减少随着越来越多的文件被检查(验证)。另外,由于递归结束,ir-chk会变成to-chk,表示增量递归扫描已结束执行其检查(文件检测操作)。尽管如此,因为文件将一直被检查/验证,直到所有文件都被检查/验证,尚未检查/验证的文件数量(斜线左侧)将减少,直到该数量变为零(表示文件验证过程结束) .

N为要检查/验证的实际文件总数,当整个过程结束时,您将看到:

to-chk=0/N
Run Code Online (Sandbox Code Playgroud)

...意味着在增量递归扫描检测到的总共N 个文件中,没有要检查/验证的文件。

关于ir-chk(来自 rsync 的手册页):

在增量递归扫描中,rsync 在到达扫描结束之前不会知道文件列表中的文件总数,但是由于它在扫描期间开始传输文件,因此它会显示一行带有文本“ ir-chk”(用于增量递归检查)而不是“to-chk”,直到它知道列表的完整大小,此时它将切换到使用“to-chk”。因此,看到“ir-chk”让您知道文件列表中的文件总数仍在增加(并且每次增加时,要检查的文件数将增加添加到的文件数)列表)。

  • @wingedsubmariner 在复制文件时 - 例如,`file1` -,rsync 向您显示整个复制过程的(当前)全局 ETA。然后,当它完成复制 `file1` 时,rsync 向您显示(当前)全局经过时间,然后开始复制下一个文件 - 例如,`file2` -,从而再次向您显示(当前)全局 ETA,直到复制`file2` 进程结束,然后 rsync 向您显示新的(增加的)总经过时间。这就是您看到这些“跳跃”的原因:这是因为您看到全球(总)ETA 减少与全球(总)经过时间增加交替。 (7认同)
  • 一个小更正:2:50 不是预计到达时间 - 这是到目前为止已经过去的时间。 (6认同)
  • 我发现跑步时 2:50 的值会减少,但通常在跳跃时会增加。这绝对是预计到达时间,而不是经过的时间。奇怪的是,第一次启动时,它似乎随着时间的推移而增加,就好像它在跟踪经过的时间一样。 (6认同)
  • 如果您不想进行增量扫描(以查看实际的 ETA),请使用“--no-ir”选项。*可以使用“--no-inc-recursive”选项或其较短的“--no-ir”别名禁用增量递归。* (6认同)
  • @YuriSucupira 我的回应是对该评论的回应。我倾向于总是使用`--no-inc-recursive`,但这不是我要说的。`progress2` 中的 ETA 时间基于总(已知)数据和经过的时间;它不是每个文件(但在单个文件完成时会闪烁单个文件时间经过值以进行刻度)。[曾经有一个涉及此问题的错误](https://lists.samba.org/archive/rsync/2014-January/029057.html) 这会使这不太清楚,尽管我不确定它是什么版本在 (5认同)
  • @YuriSucupira 党!你是对的(关于在 ETA 和 elapsed 之间交替)。这根本不是一个令人困惑的 UI 决定...... (/s)。FWIW,`man` 页面只提到了 ETA 行为:`...如果当前速率保持到结束,传输**将在 4 秒内完成**` (3认同)
  • @Izkata 我记得当时(2016 年 7 月 17 日)测试 rsync,然后在这里发表任何声明,只是为了确保 ETA 是每个文件而不是全局的,然后我“在视觉上确信”它是每个文件- 文件预计到达时间。我使用的是 XUbuntu 14.04(不记得它是哪个 rsync 版本)。无论如何,几个月前我安装了 XUbuntu 16.04(它带有 rsync 3.1.1-3ubuntu1),我可以(从视觉上)确认 `rsync -a --info=progress2 /src /dest` 实际上给了我全部时间时间与 **global** ETA 交替,而不是每个文件的 ETA。这对我来说很奇怪也很新鲜,但你是对的。 (2认同)
  • @ijoseph 是的,手册页只提到了 ETA 行为。这就是为什么这么多人在重建过程中对 UI 的行为感到困惑的可能原因之一。我自己不得不密切关注这个过程一段时间,直到我终于可以揭开它的“奥秘”。:) (2认同)
  • @Tommy 跳跃的发生是因为“增量递归”的实现。这意味着当 rsync 启动时,它并不知道所有文件。它扫描“第一个”文件夹,看到大约 10k 个文件,并基于此输出百分比。当传输正在进行时,它会继续扫描“第二个”文件夹中的更多文件,因此当完成时,总计数会增加(例如现在为 20k),因此百分比将相应减少。使用“--no-inc-recursive”将使其提前知道所有文件,但会使用更多的内存和更多的启动时间 (2认同)