Yo Lars! On Mon, 27 May 2013 10:13:00 +0200 Lars Ellenberg <lars.ellenb...@linbit.com> wrote:
> > No clue, if it does not have Chuck Handshy's patch we have issues
> > with 1.34, otherwise my results have been good.
>
> The timeout parameter is "better" than that patch in that the patch
> hardcodes the timeout, but the parameter makes it configurable.
Configurable prolly better since I've had to play with the timeout.
> The patch has one "advantage" still, it retries every 250ms,
> where the current source code still tries only once per second.
> If you say that makes sense, we can easily add yet an other config
> parameter for that, or just hardcode it to 250ms as well.
I found that helped too. More 4x more chances to catch the lock open in
a given time frame.
> I've never run into this problem myself, but then we usually don't use
> it in a way that operates on millions of files at once...
Not so much the number of files as the number of clients. I have one
master and 20 slaves. Sometimes if a big change set happens the
cronjob will start a new pass before the last one finished so I can
get several connection to each slave, all contending for the one lock.
That said, I have seen the lock problem with just one 'csync -cBr /'
and one 'csync2 -uBr -P [host] /'.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
g...@rellim.com Tel:+1(541)382-8588
signature.asc
Description: PGP signature
_______________________________________________ Csync2 mailing list Csync2@lists.linbit.com http://lists.linbit.com/mailman/listinfo/csync2
