> > 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.
This was my understanding as well. That when I use rsync over ssh, it would
create a new single-use rsync server at the remote side, which should
theoretically allow the local rsync to read the local file, and the remote
rsync to read the remote file, so the two can be diff'd at DAS speed without
transmitting the whole file across the network. However ...
When I did this, my initial rsync to send the whole file took 30 minutes.
Then I changed 1M in the middle of the sparse file, and did an incremental.
I expected it to complete in 6-7 minutes. I waited an hour and cancelled
the process because obviously it wasn't working. I tried several variations
of switches, and consulted the rsync discussion list, google, man pages,
etc. So far I haven't had any success at this...
During those failed tests, which take 2x longer or more than doing a full
image, I only checked the time. I did not monitor the network to see if the
file was flying across the wire. So I don't know what it was doing or why
it was taking so long.
It seems to be worth while, to try updating to the latest rsync, and to try
starting rsyncd at the remote side, to see if it will behave better than
what I've seen. Thanks for the suggestions, I'll plan to give that a try.
_______________________________________________
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/
