[PATCH] sanlock: host_message

Nir Soffer nsoffer at redhat.com
Sun Mar 2 10:38:23 UTC 2014


----- Original Message -----
> From: "David Teigland" <teigland at redhat.com>
> To: "Nir Soffer" <nsoffer at redhat.com>
> Cc: emesika at redhat.com, bazulay at redhat.com, abaron at redhat.com, fsimonce at redhat.com, smizrahi at redhat.com,
> sanlock-devel at lists.fedorahosted.org
> Sent: Thursday, February 27, 2014 8:13:21 PM
> Subject: Re: [PATCH] sanlock: host_message
> 
> > > I think the following example illustrates the problem with the current
> > > plan to use the vdsm lockspace for fencing:
> 
> I thought I was being somewhat unfair to the existing plan for
> vdsm-sanlock-fencing, so I worked out a description of it for
> myself that I think would be a reasonable solution.
> 
> I think the plan was to solve the limited problem of fencing a
> host with sanlock when network communication is lost, but the
> storage remains functional.  (And intend to solve the loss of
> both later.)  The problem I described in the last mail covered
> the loss of both.
> 
> If we assume that storage remains functional, then we can
> assume that a "reset yourself" message is received, and can
> verify this by watching the host status in the functional
> lockspace (it will eventually become "dead" after the
> necessary host_id lease timeout.)
> 
> However, we still need to be aware of the case when both
> network and storage are lost, and revert to a reasonable
> state, even if it's not to be solved entirely.
> I think the possible outcomes would be:
> 
> 1. The vdsm lockspace is cleanly removed due to the loss of
>    lockspace storage.  The "reset yourself" message that was
>    sent through the vdsm lockspace may or may not have been
>    received (depending on how quickly the lockspace was cleared.)
> 
>    1.a) if the message was received, the host will reset itself,
>         even though the lockspace was removed.
> 
>    1.b) if the message was not received, then the host will not
>         reset itself, and will remain running with no lockspace.
> 
> 2. The vdsm lockspace cannot be cleanly removed.  sanlock

What do you mean by cannot be cleanly removed?


More information about the sanlock-devel mailing list