[dm-devel] [RFC] 2 features for mptools 0.4.8
Philip R. Auld
pauld at egenera.com
Wed Apr 5 13:19:05 UTC 2006
Hi,
Rumor has it that on Wed, Apr 05, 2006 at 12:22:45AM +0200 Christophe Varoqui said:
> Hello,
>
...
>
> On a related note, is there still interest in a physical path-based
> checking, rather than the current logical path-based one ?
>
> The recent fc_host sysfs class normalisation brings a simple way to
> identify physical local endpoint with FC transport :
>
Is this FC transport specific or would it work for, say, iSCSI devices?
> local endpoint : /sys/class/fc_host/host1/port_name
> remote endpoint : /sys/class/fc_transport/target1:0:2/port_name
> logical paths on this phy :
>
> [root at s64p17bic44 ~]# file
> /sys/class/fc_transport/target1\:0\:2/device/1\:0\:2\:*/block
> /sys/class/fc_transport/target1:0:2/device/1:0:2:0/block: symbolic
> link to `../../../../../../../../block/sdaa'
> /sys/class/fc_transport/target1:0:2/device/1:0:2:512/block: symbolic
> link to `../../../../../../../../block/sdab'
> /sys/class/fc_transport/target1:0:2/device/1:0:2:513/block: symbolic
> link to `../../../../../../../../block/sdac'
> /sys/class/fc_transport/target1:0:2/device/1:0:2:514/block: symbolic
> link to `../../../../../../../../block/sdad'
> /sys/class/fc_transport/target1:0:2/device/1:0:2:515/block: symbolic
> link to `../../../../../../../../block/sdae'
> /sys/class/fc_transport/target1:0:2/device/1:0:2:516/block: symbolic
> link to `../../../../../../../../block/sdaf'
> /sys/class/fc_transport/target1:0:2/device/1:0:2:517/block: symbolic
> link to `../../../../../../../../block/sdag'
> /sys/class/fc_transport/target1:0:2/device/1:0:2:518/block: symbolic
> link to `../../../../../../../../block/sdah'
>
> Implementing this idea would mean in this example that checker status
> for sdaa applies to sda[bcdefgh].
Seems to me you may need a hybrid of both approaches. I agree that if
the target (sdaa) fails it's pretty safe to assume the LUs behind it
are gone. But just because sdaa is back does not mean the LUs are
definitely reachable again. Until sdaa comes back though there is not
much point in checking for the LUs.
It may also be useful to have it be a configuration option.
This and the fix for FASTFAIL will make the tools dependent on
specific kernel revs. How well do they handle running on slightly
older kernels?
Cheers,
Phil
>
> Arguments in favor of this approach are :
>
> 1) less checking work
> 2) lower failure-to-reaction latency : batched reactions upon phy path
> failure.
> 3) lessen the checking time drift : setup interval is I, but the real
> interval is "I+(checker loop time)"
> 4) each path check involves I/O, thus quite a high latency. Less checks
> means higher efficiency.
>
> I'm open for comments.
>
> Regards,
> cvaroqui
>
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
--
Philip R. Auld, Ph.D. Egenera, Inc.
Software Architect 165 Forest St.
(508) 858-2628 Marlboro, MA 01752
More information about the dm-devel
mailing list