[Csync2] retry inotify daemon and csync2

Lars Ellenberg lars.ellenberg at linbit.com
Wed Jan 14 08:59:16 CET 2009


On Tue, Jan 13, 2009 at 06:53:18PM +0100, Art -kwaak- van Breemen wrote:
> On Tue, Dec 30, 2008 at 04:36:23PM +0100, Lars Ellenberg wrote:
> > svn revision 404 adds contrib/csync2id.pl,
> > the csync2 inotify daemon.
> w00t.
> Heh, I've noticed the first problem already:
> The inotify is that fast that on incoming updates using inetd,
> before the database is updated by that process, the inotify
> daemon has already hinted *and* checked the file as being
> changed, and dirty.
> On the next update it goes back to the originator to find out the
> originator has the same file ;-).
> So, if you have a cluster of 10 servers or so, a single file
> update can result in an explosion of updates :-).
> 
> The best way is to fork off the csync2 -i from the inotify
> daemon, and while any csync2 -i is running, stop doing any checks.
> When the checks run after the -i has finished, it will notice
> nothing has changed, and hence no dirty jobs will be created.
> 
> I've noticed this when I started the daemon on a slave, that "out
> of nothing" had created 400k jobs :-).

so you suggest to remove any stand-alone or inetd csync2,
but add to your csync2id.pl daemon
a listen(), select(), accept(), fork(), exec csync2(), waitpid()
thingy?
and while that is running,
  only queue inotify events, but not process them?
  or ignore them?

are you going to patch that in?

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.


More information about the Csync2 mailing list