68

If I run rsync with --info=progress2, I get an output like

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

But what do the single numbers mean? I haven't found a matching entry in the man page.

  • The first number seems to be the amount of data which was processed (the actual copied bytes as well as the bytes skipped, because they were already existing at the target location), right? It seem not to be the number of transferred data, because it increases faster than my internet connection is...
  • Does the percentage refer to the amount of data or the number of files to be copied? Does it consider excluded files and files that are already up to date at the target location?
  • The time at third position first seemed to be an time estimation for completion, but when I tried it, it jumped between few hours and a few seconds. What does it refer to, and how is it calculated?
  • What do the last two numbers mean?
84
105.45M 13% 602.83kB/s 0:02:50 (xfr#495, ir-chk=1020/3825)

Means that:

  • The receiver/destination has so far reconstructed 105.45 megabytes (or 13%) of the approximately 811.15 megabytes (100%) of the sender's/source’s files.
  • These files are being reconstructed at a rate of 602.83 kilobytes per second and this data transfer operation so far took 2 minutes and 50 seconds (elapsed time).

Also, xfr#495 means that currently the 495th file is being transferred, while ir-chk=1020/3825 indicates that, out of a total of (so far) 3825 files recursively scanned (detected), so far 1020 of them are still to be checked/verified.

It means that if the scan detects e.g. more 100 files to be checked, both sides will increment by 100 (it will then read ir-chk=1120/3925). After all files have been scanned (detected by the incremental recursion scan), the number at the right side of the slash will remain the same until the end of the whole process, while the one at the left side of the slash will begin to decrease as more and more files are checked (verified). Also, due to the end of the recursion, ir-chk will change to to-chk, indicating that the incremental recursion scan has ended performing its checking (file detection operation). Still, because the files will keep being checked/verified until all of them are, the number of files yet to check/verify (left side of the slash) will decrease until such number becomes zero (indicating the end of the file verification process).

Let N be the actual total number of files to be checked/verified, when the whole process ends you'll see:

to-chk=0/N

...meaning there's no file left to be checked/verified, out of a total of N files that were detected by the incremental recursion scan.

About ir-chk (from rsync's manual page):

In an incremental recursion scan, rsync won’t know the total number of files in the file-list until it reaches the ends of the scan, but since it starts to transfer files during the scan, it will display a line with the text "ir-chk" (for incremental recursion check) instead of "to-chk" until the point that it knows the full size of the list, at which point it will switch to using "to-chk". Thus, seeing "ir-chk" lets you know that the total count of files in the file list is still going to increase (and each time it does, the count of files left to check will increase by the number of the files added to the list).

  • 4
    A minor correction: The 2:50 is not an ETA - it's the time elapsed so far. – sneak Mar 10 '16 at 18:06
  • 1
    ir-chk goes down, so I guess it's the number of remaining files to check, not the number of checked files. Sometimes both remaining and total will go up, as rsync discovers more files I suppose. – Pikrass May 16 '16 at 7:36
  • 4
    @YuriSucupira My response is to that comment. I tend to always use --no-inc-recursive, but that's not what I'm talking about. The time ETA in progress2 is based on total (known) data and time elapsed; it isn't per-file (but does blink the single-file-time-elapsed value for a tick upon a single file completion). There was a bug involving this at one point that would make this less clear, though I'm not sure what version it's in – Izkata Oct 16 '16 at 21:58
  • 2
    @Izkata I recall testing rsync by that time (July 17, 2016), before making any statement here, just to make sure that the ETA was per-file instead of global, and I was then "visually convinced" that it was a per-file ETA. I was using XUbuntu 14.04 (don't recall which rsync version it was). Anyway, I installed XUbuntu 16.04 (it comes with rsync 3.1.1-3ubuntu1) a couple of months ago and I can (visually) confirm that rsync -a --info=progress2 /src /dest in fact gives me total elapsed time alternating with global ETA, instead of per-file ETA. That's weird and new to me, but you're right. – Yuri Sucupira Oct 17 '16 at 5:03
  • 3
    @wingedsubmariner While it's copying a file - say, file1 -, rsync shows you the (current) global ETA for the entire copy process. Then, when it finishes copying file1, rsync shows you the (current) global elapsed time, and then starts copying the next file - say, file2 -, thus showing you the (current) global ETA again, until the copy process of file2 ends and then rsync shows you the new (incremented) total elapsed time. This is why you see those "jumps": it's because you see a decreasing global (total) ETA alternating with the increasing global (total) elapsed time. – Yuri Sucupira Oct 17 '16 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.