rsync and xfr#1, to-chk=0/1, what do they mean?

Question

I do stuff such as :-

$ copy debian-8.2.0-amd64-DVD-1.iso /media/shirish/4719-38E5/

Copy here is an alias for :-

$ alias copy
alias copy='rsync --progress -ravz'

When it does the command it takes a long time to complete and does :-

$ copy debian-8.2.0-amd64-DVD-1.iso /media/shirish/4719-38E5/
sending incremental file list
debian-8.2.0-amd64-DVD-1.iso
  3,607,855,104 100%    9.11MB/s    0:06:17 (xfr#1, to-chk=0/1)

sent 3,466,268,276 bytes  received 35 bytes  3,481,937.03 bytes/sec
total size is 3,607,855,104  speedup is 1.04

Now I have two questions :-

a. -z in rsync is not documented, does anybody know what does it do ? It is very much possible that the flag was there before and is no longer there.

Another thing, does anybody know what xfr#1, to-chk=0/1 actually do ?

I usually perform sync after the command is finished, does anybody know if it's ok to use it or not as copying takes a long time.

Also can people some nicer, better ways so I could use an alias to accomplish the same. For me having progress is important. Few months ago, I did come across an advanced cp which also has a progress bar for showing the progress of a file being copied.

Hopeful of a quick resolution of the above.

Answer 1

It got solved -

-z, --compress              compress file data during the transfer
    --compress-level=NUM    explicitly set compression level

this part seems to be the interesting one.

    --progress

This option tells rsync to print information showing the progress of the transfer. This gives a bored user something to watch. With a modern rsync this is the same as specifying

    --info=flist2,name,progress

but any user-supplied settings for those info flags takes precedence (e.g. "--info=flist0 --progress").

While rsync is transferring a regular file, it updates a progress line that looks like this:

782448  63%  110.64kB/s    0:00:04

In this example, the receiver has reconstructed 782448 bytes or 63% of the sender’s file, which is being reconstructed at a rate of 110.64 kilobytes per second, and the transfer will finish in 4 seconds if the current rate is maintained until the end.

These statistics can be misleading if rsync’s delta-transfer algorithm is in use. For example, if the sender’s file consists of the basis file followed by additional data, the reported rate will probably drop dramatically when the receiver gets to the literal data, and the transfer will probably take much longer to finish than the receiver estimated as it was finishing the matched part of the file.

When the file transfer finishes, rsync replaces the progress line with a summary line that looks like this:

1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)

In this example, the file was 1,238,099 bytes long in total, the average rate of transfer for the whole file was 146.38 kilobytes per second over the 8 seconds that it took to complete, it was the 5th transfer of a regular file during the current rsync session, and there are 169 more files for the receiver to check (to see if they are up-to-date or not) remaining out of the 396 total files in the file-list.

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).