NLM and CTDB recovery master node failure

Sergey Kleyman Sergey.Kleyman at exanet.com
Thu Oct 29 13:20:30 MDT 2009


> -----Original Message-----
> From: Volker Lendecke [mailto:Volker.Lendecke at SerNet.DE]
> Sent: Thursday, October 29, 2009 17:48
> To: Sergey Kleyman
> Cc: samba-technical at lists.samba.org
> Subject: Re: NLM and CTDB recovery master node failure
> 
> On Thu, Oct 29, 2009 at 04:34:14PM +0100, Volker Lendecke wrote:
> > Please use a different cluster file system that does not exhibit
this
> > behaviour or run without the central reclockfile.
> 
> Ok, I've got a question: Can we achieve the same result we use the
> fcntl lock on the reclockfile for with another API on your system?
> 
> We need to very quickly determine correct cluster membership of all
> ctdb nodes: If nobody can get the reclock lock, then we're broken. If
> more than one can get it, we've got a split brain. How can we get that
> info reliably out of your cluster fs without using the fcntl lock?
> 
> Volker

We have our internal API that are implemented on top of Spread Toolkit
(http://www.spread.org/) but our goal is to make as less changes to
Samba as possible so changing election code to use our API is not the
optimal solution. I guess it'll be easier to adhere to Samba's
assumptions about NLM and provide automatic lock clean-up in case of the
node failure. Are you sure that GPFS and/or GFS have this capability?

As a side note: if I understand you correctly CTDB is assumed to be
running on the same machines as underlying file system. I was under the
impression that it's possible to run file system on machines A and B,
while Samba+CTDB will run on different machines C and D that will see
clustered file system through NFS mounts in which case C and D are just
NLM clients to the file system.

One more point I wanted to inquire about: if smbd daemons dies for some
reason (abnormal exit - panic, etc.) what happens to CIFS locks it was
holding? Are those locks automatically cleaned up?

Thanks, Sergey


More information about the samba-technical mailing list