On 2010-02-18 at 22:10 -0600, Brad Knowles wrote:
> 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.
Actually, I believe this happens anyway.
The normal mode of operation, where you use ssh/rsh to connect to a
remote host, invokes { rsync --server --sender } on the remote side.
I'm not aware of any mode of operation in which rsync pulls the entire
contents of a file from remote in order to minimise what is sent to the
remote; that seems counter-intuitive, but I'm not expert in the workings
of rsync. (I looked into it a little a few years ago, to have restricted
rsync-over-ssh via command="rsync --server [...]" in authorized_keys, to
permit only very restricted rsync access with a dedicated ssh key;
worked nicely.)
-Phil
_______________________________________________
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/
