On 10/09/13 03:38, ame...@gmail.com wrote:
> It's great you brought up bbcp. I didn't factor this into my initial
> email, but if we could further split up large files into N chunks and
> transport them concurrently, that would provide massive benefits as
> well.
>
> It's clear there are multiple
ect: Re: Native Parallelization in rsync
On 08/09/13 18:28, francis.montag...@inria.fr wrote:
> There is another rather common case I think where this would help:
> when the destination directory is located on a NAS over NFS.
I think the biggest use-case is high bandwidth, high latency links
On 08/09/13 18:28, francis.montag...@inria.fr wrote:
> There is another rather common case I think where this would help:
> when the destination directory is located on a NAS over NFS.
I think the biggest use-case is high bandwidth, high latency links. eg
you have a 50Mbs WAN link to a site in ano
On Thu, 05 Sep 2013 20:04:21 +0200 "Stier, Matthew" wrote:
> The only time I've seen where some kind of threading would have help,
> is I was trying to transfer hundreds of gigabytes of data across a
> gigabyte link. ...
There is another rather common case I think where this would help:
when the
, 2013 6:29 PM
To: rsync@lists.samba.org
Subject: Native Parallelization in rsync
I'm sure this is a topic that's come up plenty of times before, but is it
possible to implement native parallelization in rsync? There are several blog
posts listing workarounds, but they are largely un
I'm sure this is a topic that's come up plenty of times before, but is it
possible to implement native parallelization in rsync? There are several blog
posts listing workarounds, but they are largely unideal.
My initial thought would be that rsync could split up the file lis
