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.
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
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. “
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).