[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