On Tue 30 Jan 2007, Paul Slootman wrote:
Still going strong :)
Still running ;)
One note: don't forget to fix the copyright notice on rsync,
s/2006/2007/ :
# rsync --version
rsync version 3.0.0cvs protocol version 30
Copyright (C) 1996-2006 by Andrew Tridgell, Wayne Davison, and others.
On Mon 29 Jan 2007, Wayne Davison wrote:
On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote:
Unfortunately the current CVS version (updated a couple of hours ago)
still hangs :(
I found another potential hang scenario that could happen if the
generator was having to wait for a
Same here. I did my initial test and where before it used to hang, it
doesn't now :)
Thanks for tonight's update!
Shai
On 1/30/07, Paul Slootman [EMAIL PROTECTED] wrote:
On Mon 29 Jan 2007, Wayne Davison wrote:
On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote:
Unfortunately
On Tue, Jan 30, 2007 at 02:38:42PM +0100, Paul Slootman wrote:
It also did the sync in under 2 hours, whereas the non-incremental
version would take up to 12 hours, and use up to 500MB of memory.
Awesome! That's an even more dramatic improvement than what I was
anticipating for large
On Tue, Jan 30, 2007 at 05:21:35PM +0200, Shai wrote:
Same here. I did my initial test and where before it used to hang, it
doesn't now :)
Thanks for the update! I appreciate your help in the testing. If you
have any speed comparisons between old and new rsync runs for your setup
(approximate
On Tue 30 Jan 2007, Wayne Davison wrote:
On Tue, Jan 30, 2007 at 02:38:42PM +0100, Paul Slootman wrote:
It also did the sync in under 2 hours, whereas the non-incremental
version would take up to 12 hours, and use up to 500MB of memory.
Awesome! That's an even more dramatic improvement
Sweet! I'll test it soon!
On 1/27/07, Wayne Davison [EMAIL PROTECTED] wrote:
On Sun, Jan 21, 2007 at 08:43:56AM +0200, Shai wrote:
When I start the rsync, either with the rsync protocol or rsh, i found
that it'll start doing the rsync and just halt after a few hundred MBs
or even up to a
On Sat 27 Jan 2007, Wayne Davison wrote:
I had not encountered this hang until today. The backtrace implicated
a problem in the wait_for_receiver() routine, and I figured out that
every now and then the io_flush() call could end up reading the last
available message from the receiver, giving
On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote:
Just now, with various straces running, the sending process got to:
The important process in the generator, since it controls all the work.
(It is the first process on the receiving side, and forks the receiver).
Attaching to the
On Mon, Jan 29, 2007 at 06:33:19PM +0100, Paul Slootman wrote:
Unfortunately the current CVS version (updated a couple of hours ago)
still hangs :(
I found another potential hang scenario that could happen if the
generator was having to wait for a new file list to arrive, but failed
to tell the
On Mon 22 Jan 2007, Paul Slootman wrote:
It's the same binary, compiled from rsync-HEAD-20070120-2211GMT.
I tried again with current cvs (with the 1.194 version of receiver.c),
and it still hangs when transferring an empty directory (it is created
on the receiver though). A local transfer
On Sun 21 Jan 2007, Wayne Davison wrote:
Another thing you can do in the debugger when attached to the generator
is to output a summary of the file-list info:
p *first_flist
p *first_flist-next
p *first_flist-next-next
I just noticed that rsync-HEAD-20070120-2211GMT will hang when
On 1/22/07, Paul Slootman [EMAIL PROTECTED] wrote:
I just noticed that rsync-HEAD-20070120-2211GMT will hang when
transferring an empty directory:
I can't reproduce this hang in the current rsync from CVS. I tried
pushing an empty directory to a daemon on the same machine, but rsync
finished
On Mon 22 Jan 2007, Matt McCutchen wrote:
I can't reproduce this hang in the current rsync from CVS. I tried
pushing an empty directory to a daemon on the same machine, but rsync
finished successfully.
This was to another system, over Gbit ethernet; both sides are amd64,
running in 64 bits
On Mon, Jan 22, 2007 at 10:04:10PM +0100, Paul Slootman wrote:
This was to another system, over Gbit ethernet; both sides are amd64,
running in 64 bits mode.
Make sure that both sides are running the exact same code for protocol
30 (because the protocol is still in flux). If one side is older,
On Mon 22 Jan 2007, Wayne Davison wrote:
On Mon, Jan 22, 2007 at 10:04:10PM +0100, Paul Slootman wrote:
This was to another system, over Gbit ethernet; both sides are amd64,
running in 64 bits mode.
Make sure that both sides are running the exact same code for protocol
30 (because the
On 1/21/07, Shai [EMAIL PROTECTED] wrote:
I've wanted to start working with this CVS version cuz the new
incremental-recursion algorithm is just what I need. But ran into a
problem...
When I start the rsync, either with the rsync protocol or rsh, i found that
it'll start doing the rsync and
On Sun, Jan 21, 2007 at 08:23:25AM -0500, Matt McCutchen wrote:
I had a similar problem, and Wayne is in the process of fixing it.
Right now he's waiting for me to provide backtraces for the hung
processes, which I will do very soon.
Another thing you can do in the debugger when attached to
On 1/21/07, Wayne Davison [EMAIL PROTECTED] wrote:
I'm thinking that I will add a debug-output signal handler, probably
listening on SIGALRM. This will let the user kill -14 any rsync 3.0.0
process to have it mention its role and some debug info.
I like this idea!
Matt
--
To unsubscribe or
Hi,
I've wanted to start working with this CVS version cuz the new
incremental-recursion algorithm is just what I need. But ran into a
problem...
When I start the rsync, either with the rsync protocol or rsh, i found that
it'll start doing the rsync and just halt after a few hundred MBs or even
20 matches
Mail list logo
