CTDB with GlusterFS.

Martin Schwenke martin at meltin.net
Fri Nov 13 09:10:37 UTC 2015

On Thu, 12 Nov 2015 07:42:00 +0100, Michael Adam <obnox at samba.org>

> On 2015-11-12 at 13:51 +1100, Martin Schwenke wrote:
> > On Wed, 11 Nov 2015 07:26:03 +0100, Ralph Boehme <rb at sernet.de> wrote:
> >   
> > > On Wed, Nov 11, 2015 at 05:12:31PM +1100, Martin Schwenke wrote:  
>  [...]  
> > > 
> > > fwiw, I have this WIP patch for ping_pong in a working branch.  
> > 
> > I think we discussed this some time ago and some of us thought there
> > were better ways.  I think one reply was probably that it didn't
> > belong in ping_pong.   Also, Michael pointed out another way using
> > existing ping_pong functionality.
> > 
> > However, I think your patch creates a very obvious way of testing
> > byte-range locks and we should think about how it can be cleaned
> > up and pushed.
> > 
> > You probably need to clean up the repetitive usage checking...  :-)
> > 
> > Interested to hear what others think.  
> Just because scripting was mentioned before:
> I had in the past started to write a ping_pong clone in python
> to allow for more agile hacking on it. Here it is:
> git://git.samba.org/obnox/ping-pong-py.git
> Also available under
> https://github.com/obnoxxx/ping-pong-py.git

Very cool!  As you seem to be suggesting, I wonder if we want to
consider using this instead of the C version because it lowers the
barrier to entry?  The argument against it would be that it adds a
layer, so a Python bug (unlikely, I guess) might cause false test

I'm not sure if we've had this conversation, but my medium term plan is
to break out the "recovery lock" fcntl-lock-a-file-as-a-mutex code into
an external helper program (I think we started this conversation with
Richard) and call that from CTDB. Then the helper could easily be
replaced with some other way of getting a cluster-wide mutex.  There
was something blocking progress on this and I'll have to look back
through emails to remember what it was...  it could be the untangling
work that I've started.

Hopefully, we could then call that same helper from a test script to
actually run the locking verification tests across all the nodes.  For
example, you could setup the nodes file and use test scripts that use
onnode to try taking various types of locks.  This would make the
locking tests more objective than with the current ping_pong (e.g. did
it "slow down"?).

So, I guess one question is how much work do we do on ping_pong?  :-)

peace & happiness,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 173 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20151113/071f43f8/attachment.sig>

More information about the samba-technical mailing list