CTDB with GlusterFS.

[Michael Adam]

On 2015-11-13 at 20:10 +1100, Martin Schwenke wrote:
> On Thu, 12 Nov 2015 07:42:00 +0100, Michael Adam <obnox at samba.org>
> wrote:
> 
> > 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
> results.

I am  quite frankly not 100 % certain what I am suggesting
or whether I am suggesting anything really... :-)

Indeed the entry barrier and the ability to quickly hack
on a test tool w/o the need to have a compiler around is
the appeal.

Python does add a layer to pure C coding, so I generally
see lower locks/second rates with the python tool than with
the compiled C program. So I don't think I want to completely
replace our good old ping_pong.c right now.


> 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.

Yeah, we had the conversation, not sure. Around sambaXP possibly.

The approach sounds great.
I don't think it would get us rid of ping_pong entirely.
E.g. if s/o wants to test lock performance it might still
be handy.

Also, a (possibly extended) python ping-pong tool could
be used as an external tool that people can just download
and use to test the aptness of their system for ctdb with
fcntl locking for recovery mutex.

Just thinking aloud...

Cheers - Michael

> 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,
> martin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20151113/1dbeb45e/signature.sig>