Mark,
I reverted back to rsync 2.3.2 after a massive complain from our user trying to get
their data from their machine to the target sites. Since rsync been running very
smoothly.
Just as a background. I have been using rsync for about 3 years now and been using
2.3.2 since it came out.
On Mon, May 14, 2001 at 03:12:27PM +1200, Wilson, Mark - MST wrote:
Dave
A couple of points:
1. I think you are telling me that if I go back to 2.3.2 my problems should
go away. Is this correct?
Hopefully, assuming you trigger the optimization (no wildcards in the
includes followed by an
On Mon, May 14, 2001 at 11:13:40AM -0500, Dave Dykstra wrote:
...
As a thought, have you or any of the other developers thought of getting
rsync to operate over a number of streams or to use sliding windows to
overcome latency effects?
I don't recall that that subject has been discussed
On Fri, 11 May 2001, Dave Dykstra wrote:
The optimization bypassed the normal recursive traversal of all the
files and directly opened the included files and sent the list over.
There's an alternative to this optimization: if we could read the
source files from a file (or stdin), we could use
On Mon, May 14, 2001 at 01:32:01PM -0700, Wayne Davison wrote:
On Fri, 11 May 2001, Dave Dykstra wrote:
The optimization bypassed the normal recursive traversal of all the
files and directly opened the included files and sent the list over.
There's an alternative to this optimization: if
Try rsync 2.3.2 on both ends and see what the result is.
What transport method are you using (rsh, ssh, or rsync --daemon mode)?
--daemon mode. Some tests a colleague did showed a performance advantage.
Come to think of it, I know from experience that rsync is able to keep the
TCP
