DO NOT REPLY [Bug 3358] rsync chokes on large files

bugzilla-daemon at bugzilla-daemon at
Mon Jan 2 18:02:21 GMT 2006

------- Comment #7 from wayned at  2006-01-02 11:02 MST -------
(In reply to comment #6)
> This is weird, there is no network activity during this building file list
> phase. However, as soon as it is finished, rsync saturates my network.

What is weird about that?  As soon as rsync outputs the "1 file to consider"
message, the file-list-building stage is over, and rsync then starts to
transfer the file if it is in need of an update.  (If --checksum was specified,
the receiving rsync would first be busily checksumming the file to decide if
the file was actually changed before (possibly) starting the transfer.)

> I thought rsync worked, if the file's size and modification date doesn't
> match, by creating a binary tree and then checksumming the parts between
> every node, recursively to the root of the tree, and then only transferring
> the parts where the checksum didn't match.

There are no b-trees involved -- rsync immediately starts to send checksum info
from the receiving side to the sender, who then diffs the remote checksums with
the sending-side file and sends instructions to the receiver on how to recreate
the file using as much of the local data as possible (this new file is built in
a separate temp-file unless the --inplace option was specified).

Configure bugmail:
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

More information about the rsync mailing list