Need hint for my question regarding the working of rsync.
kmk at sanitarium.net
Tue Nov 12 15:25:53 MST 2013
-----BEGIN PGP SIGNED MESSAGE-----
First, are you talking about --checksum checksums or the hashing of
files that are different on both ends so that only the differences
need to be transferred? You seem to be talking about the latter while
describing the performance of the former.
If you are talking about --checksum then you should know that it is
only there for a few very unusual use cases. It most normal(ish) use
cases --checksum is slower than simply re-copying everything and
especially re-hashing everything (--ignore-times).
On 11/12/13 17:13, Karl O. Pinc wrote:
> On 11/12/2013 03:50:20 PM, Wayne Davison wrote
>> Yes, the receiver sends all the checksums that it generates at
>> For really big files it would be interesting to amend this rule
>> to one where the sending side waits only long enough for a
>> certain number of checksums to arrive before it begins its work
>> (and perhaps pauses if it gets too far ahead of the arriving
> Based on the behavior I see when using rsync, without really
> knowing what's going on, it seems that the sending side first does
> a lot of disk access, then the receiving side does, and then the
> sync begins over the network. It would save a lot of wall-clock
> time if the sending and receiving side could both be hitting the
> disk at once. At least in my use case, with whatever version of
> rsync I happen to be using.
> Karl <kop at meme.com> Free Software: "You don't pay back, you pay
> forward." -- Robert A. Heinlein
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. Kevin at FutureQuest.net (work)
Orlando, Florida kmk at sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the rsync