Wayne Davison wrote:
> We certainly do need to be careful here, since the interaction between
> the various read and write functions can be pretty complex. However, I
> think that the data flow of my move-files patch stress-tests this code
> fairly well, so once we've done some more testing I feel that we will
> not leave rsync worse off than it was before the patch.
>
> Along those lines, I've been testing the new code plus I ported a
> version of my move-files patch on top of it. The result has a couple
> fewer bugs and seems to be working well so far.
>
> The latest non-expanding-buffer-nohang patch is in the same place:
>
> http://www.clari.net/~wayne/rsync-nohang2.patch
>
> and the new move-files patch that works with nohang2 is here:
>
> http://www.clari.net/~wayne/rsync-move-files2.patch
>
> I'll keep banging on it. Let me know what you think.
So far it is working for me. Now I can kill my client side and know
that my daemon side will properly close down and exit and not leave
a dangling lock.
But the problem I still have (not quite as bad as before because of
no more hangs) is that the locks to control the number of daemons is
still working wrong. It's still locking the whole lock file instead
of the first lockable 4 byte record. I still don't know if it is
rsync or Linux causing the problem. The code in both looks right to
me. But lslk shows:
SRC PID DEV INUM SZ TY M ST WH END LEN NAME
rsyncd 24401 3,5 44 0 w 0 0 0 0 0 /tmp/rsyncd.lock
(note, I've been moving the lock file around to see if it might be
sensitive to filesystem mounting options I'm using, etc).
I'd like to find a way to start rsync in daemon mode AND leave it
in the foreground so I can run it via strace and maybe see if the
syscall is being done right.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
