delta copies

Matt McCutchen hashproduct+rsync at
Sun Sep 23 00:00:12 GMT 2007

On 9/22/07, Robert Fitzpatrick <lists at> wrote:
> I do a
> simple tar of /var twice and then rsync the two files only as a test, no
> folders involved....trying to determine why the entire file is being
> copied in its entirety and not synchronized bit-by-bit.

> esmtp# rsync -az --progress --stats test/ test2/
> building file list ...
> 2 files to consider
> ./
> testvar.tar
>   1298128896 100%   13.00MB/s    0:01:35  (1, 100.0% of 2)
> Number of files: 2
> Number of files transferred: 1
> Total file size: 1298128896 bytes
> Total transferred file size: 1298128896 bytes
> Literal data: 1298128896 bytes
> Matched data: 0 bytes
> File list size: 53
> File list generation time: 0.001 seconds
> File list transfer time: 0.000 seconds
> Total bytes sent: 178178479
> Total bytes received: 48
> sent 178178479 bytes  received 48 bytes  1846409.61 bytes/sec
> total size is 1298128896  speedup is 7.29

Delta transfers reduce network traffic between the sending and
receiving rsync processes at the cost of some extra CPU time and disk
I/O (e.g., the receiver has to read the old destination file).  The
reduction in network traffic is only relevant if the two processes are
on different machines.  When they are on the same machine as in your
example, there is no point in doing delta transfers, so by default
rsync does not do them.  You can force rsync to do delta transfers by
passing --no-whole-file, but I can't imagine why you would want to do
this unless you are testing to see how much traffic reduction delta
transfers would achieve.

> Also, does the match data bytes show the amount
> matched when making delta copies, I assume?

Yes.  More precisely, it shows the amount that rsync found to be
matched.  Rsync's goal is to match as much data as convenient, not to
give you an exact measure of how much of the file changed.


More information about the rsync mailing list