On 7/3/11 1:57 PM, Holger Parplies wrote:
>
>> An rsync full means read everything at both ends but only send the
>> differences.
>>    There can be a lot of dead air in the process.
>
> I'm not sure how that exchange happens. Is it one large list with all the
> details at the start (i.e. file list + checksums for all files)? Does the
> receiver really need to compute checksums for *all* files (with
> --ignore-times), even those the sender side would send anyway due to changed
> attributes?

I'm not sure about the details myself, but I've seen the long idle times and it 
has come up as a problem on the list before - and can be fixed either with 
keep-alives on the connection or increasing the idle timer for connections on 
the router/firewall.

> Wouldn't that mean reading those files twice? That would certainly
> explain why checksum caching makes such a difference (maybe I should switch it
> on ;-).

Rsync has some sort of sliding block window to zoom in on changes, not sure 
about inode/attribute changes that don't involve the file contents.  They might 
always be sent anyway.  Checksum caching only affects the server side - the 
sender has to do the reads anyway.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/