CTDB and Recovery lock
martin at meltin.net
Wed Nov 18 08:18:50 UTC 2015
On Tue, 17 Nov 2015 14:00:11 -0800, Partha Sarathi
<parthasarathi.bl at gmail.com> wrote:
> > > Also we don't have our Clustered Filesystem with Posix locking
> > > support but we do have Consensus/Conspiracy service available in
> > > cluster, is it possible to make use of that infrastructure to
> > > mimic the recovery file lock mechanism ?
> > Not today. Hopefully soon. As I untangle some of this I will make the
> > "exclusive" lock code call out to a configurable helper program.
> Thanks a lot Martin for your detailed answers.
> Now I am more interested about the "configurable helper program" you
> mentioned which replaces the recovery lock mechanism. May I know little
> more about it ?.
We are thinking of an executable similar to the current
ctdb_event_helper. This would take some file descriptors for status
and logging, and whatever other arguments are needed - for the fcntl(2)
helper the only other argument would probably be the filename.
The behaviour would be something like this:
* If the cluster-wide mutex can be taken then write 0 to the status file
descriptor and hold the mutex until terminated with a signal or the
* If the cluster-wide mutex can't be taken then write non-0 (or nothing)
to the status file descriptor, potentially write some messages to the
logging file descriptor, and exit. It would probably make sense to
write an errno to the status file descriptor so CTDB can tell if
there was contention for the mutex (e.g. EACCES or EAGAIN) or some
other error. We would need some sort of convention - I won't invent
it now. :-)
* When CTDB wants to release the mutex it could send SIGTERM.
* If the parent exits then release the mutex and exit.
How does that sound?
As I said, there is probably a bit more untangling to do before this
can be implemented. I hope this can be done before Samba 4.4 is
released in March 2016.
peace & happiness,
More information about the samba-technical