Max filesize for rsync?

Shachar Shemesh rsync at
Thu Apr 14 06:21:32 GMT 2005

Tony at wrote:

>I would be very happy to test any patches. (Assorted RedHat/Fedora i386)
>(Assume I am a total newbie, much safer that way)
>A few very large files regularly rsync'd in production.
>Seems like it sometimes gets somewhat stuck in the middle of something
>(The rsync is mostly staging area to staging area.
>Plenty of redundancy, so I'm unlikely to get hurt if I'm aware of problems.
>The way the targets are used, I will know about problems before any real
>damage is done.)
>The more important of the transfers are over occasionally very bad internet
>connections, so I'm pretty much in the situation of something to gain,
>nothing to lose.
>-rw-rw----    1 27       27       1187270120 Apr 13 03:24
>-rw-rw----    1 27       27       1098515060 Apr  8 07:34
>-rw-rw----    1 mysql    mysql    840374964 Apr 12 12:59
>-rw-rw----    1 mysql    mysql    520216980 Apr 12 20:54
>-rw-rw----    1 mysql    mysql    221876208 Apr 11 14:21
Actually, rsync's implementation only starts to give suboptimal results 
when we pass the 2.5GB area. Up until there one should see no noticeable 
difference in performance (well, my patch can allow using somewhat less 
memory for those cases, but no one would really miss 256KB of RAM these 
days, and I'm not sure how much impact the "CPU cache" effect is going 
to have in rsync's case. I guess that some effect will be seen anyways, 
but not as noticeable).

The performance bottleneck is due to hash table buckets load. Optimal 
load, as taught at computer science, is 80% (or 0.8). Your smallest file 
puts a load of 23%, while your largest file has a load of 53%. You 
shouldn't see any problems when using rsync (at least, not the type of 
problem I'm talking about).


Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work?

More information about the rsync mailing list