On 2011-05-19T10:36:04, Ulrich Windl <[email protected]> wrote:
> reading the SFEX wiki page, I felt the main reason for confusion is the
> description of SFEX itself: "SFEX is resource which control ownership of
> shared disk"
That is true - that is the effect if properly configured and integrated
into the dependency tree of Pacemaker.
> As my reading suggests, that is not true. Instead the truth seems to be:
> "SFEX is a resource that controls ownership of shared resources by using a
> shared disk"
>
> So you see why I thought a raid needs two SFEX devices. Knowing that you can
> control multiple resources with one SFEX device, results in a different
> solution.
The integrity of all resources is already implicitly protected via
fencing. sfex effectively only makes sense where fencing isn't
available; both are advisory in the sense that they rely on proper
operation of the policy engine.
> I'll attach my handwritten comments on the page (200kB of PDF, sorry for
> that!), so maybe someone can update the wiki page. (If you grant me write
> access, I could do as well, but I don't know whether I'm right).
I do appreciate your feedback, but reading handwritten notes really
isn't the best way to go about this. You can register for the wiki
yourself, though.
> Can I say that an SFEX resource is a mutex lock, and the "-n" parameter
> specifies the number of such locks (and not the number of hosts accessing the
> lock)?
SFEX provides advisory locking, and the locks are enumerated, yes. At
sfex_init time, -n specifies the number of slots for locks on the
device. sfex_lock supports the -i switch to select one of these slots;
mapping between locks to protected services is an admin task.
It doesn't support shared locks, it is exclusive-only.
Regards,
Lars
--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
