[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Linux-cluster] Using cman,etc for a non-gfs app
- From: Lon Hohberger <lhh redhat com>
- To: linux clustering <linux-cluster redhat com>
- Subject: Re: [Linux-cluster] Using cman,etc for a non-gfs app
- Date: Wed, 20 Jul 2005 16:30:17 -0400
On Wed, 2005-07-20 at 14:31 -0400, Olivier Crete wrote:
> On Wed, 2005-20-07 at 13:49 -0400, Lon Hohberger wrote:
> > On Fri, 2005-07-15 at 18:02 -0400, Olivier Crete wrote:
> > > On Wed, 2005-22-06 at 18:36 -0400, Lon Hohberger wrote:
> > > > * libmagma provides cp_fence() / clu_fence() which work on both CMAN and
> > > > gulm.
> > >
> > > I've looked implementing clu_fence() in libmagma. It seems to only call
> > > an ioctl in the kernel cman which only seems to do cooperative fencing
> > > and removing a node from the cluster... I dont see any call to fenced or
> > > fence_node. Or have I missed something ?
> > >
> >
> > Correct, it removes the node via libgulm or asking CMAN to expire and
> > fence the node.
>
> But cman does not seem to really fence the node... just remove it from
> its list.. So that's not enough for our app that has shared storage..
> Ideally, I would need the same behavior as stonith and have the call
> block and return only when we are 100% sure that the node have been
> fenced.
It's supposed to fence it. At least, it used to fence it... I wonder
if something changed that I didn't know about?
Basically, the idea is that we tell CMAN to force-expire the node. It
should then take recovery actions to restore the node.
fenced is running, right?
-- Lon
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]