On Feb 18, 2010, at 8:43 PM, Edward Ned Harvey wrote: > The ultimate goal is to have the job completed quickly. But that can only > be done if the number of blocks sent is minimized. Presently, rsync reads > the whole local file, and also reads the whole remote file to diff them, and > send only the changed blocks. "Read the entire remote file" is the fault > here. You could write the entire remote file, faster and with less traffic, > than reading it and sending changes.
If you have rsyncd running on the remote machine instead of mounting it as a remote filesystem on the local client, then the rsync local client will communicate with the remote daemon, and they will each calculate their own respective checksums, which can then be compared. > If rsync, during the initial send, stored checksums of the internal blocks > of a file, then on subsequent sends, rsync would only need to read the local > file and recalculate checksums to see which blocks needed to be sent. This > would occur entirely at local disk speeds, with little or no network > traffic, and certainly no need to read the entire remote file. But rsync has no place to store the block checksums, so there would be no way to keep that information across invocations. If you wanted to store the block checksums, you'd have to add a whole database module to handle the storage requirements for that, and then you get into the issue of how do you store and sync this rsync internal metadata? -- Brad Knowles <[email protected]> LinkedIn Profile: <http://tinyurl.com/y8kpxu> _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
