On 2008-09-22T22:02:22, Xinwei Hu <[EMAIL PROTECTED]> wrote:
> Indeed. sfex and scsi-2 reservation are designed for 2 nodes cluster. Where
> provision of clones is not considered at all.
Still, I'd prefer if that was possible.
> And the reason I prefer scsires is sg_persist refused to work with scsi-2
> device, which is still a lot out.
I have to admit I don't know about how common SCSI-3 versus SCSI-2
devices are, but for MPIO etc, we're basically out-of-luck with SCSI-2.
If we are implementing a new feature for new systems, we might as well
specify something uptodate ;-)
> However, the idea of using sg_persist as RA is not far more complicated ;)
>
> 1. key = "$OCF_RESOURCE_INSTANCE.$nodeid" (need to shorten to 8 bytes)
> 2. key_list = sg_persist -n -d $dev -i -k (get all keys registered)
> 3. grep for $OCF_RESOURCE_INSTANCE in $key_list
> 4. if not found: sg_persist -n -d $dev -o -R -S $key -T 5
> 5. if already registered, sg_persist -n -d $dev -o -A -K $key -S
> $previouskey -T 5
A bit more complex, as the clone needs to track a _list_ of nodes
allowed to access, but they can use the list of nodes active, hash that,
and get the reservation for that ... I have to admit the idea is a bit
vague right now.
> The problem is, I need some environment to test.
Ah, yes, that'd be a problem, but I think our EMCs can do SCSI-3
reservations.
> > There's also a bunch of bugs in sfex lib - memory allocation, handling
> > of direct IO, use of fprintf instead of cl_log, non-portable types in
> You mean -Werror ? I'll take care.
Not just that, but also using "int" etc on on-disk structures, sprintf
to character arrays etc, is not really something which lets me sleep
well at night. O_DIRECT is also somewhat different from O_DSYNC|O_RSYNC.
The code is not very clean, I'm afraid.
sbd.c uses uint32 etc for a reason, as well as the conversion to and
from network byte-order. The cluster stack is capable of running in
mixed-arch clusters, and that ability needs to be preserved.
> > data written to disk, unimplemented functions ... Does sfex still
> > provide anything which sbd can't do?
> sfex can use several devices for one node, and sbd can't. (correct me
> if I'm wrong)
I'm not sure what you mean. sbd only _needs_ one shared block device; it
doesn't act as a tie-breaker for single resources, as a fencing
mechanism, it prevents split-brain before the cluster would even try to
activate resources.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (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
