[RFC] 2 features for mptools 0.4.8

[RFC] 2 features for mptools 0.4.8

[Christophe Varoqui]

Hello,

multipath-tools path checking framework has a well-known (nonetheless 
serious) design hole : a blocked check can hang the whole daemon.

Consensus was to export to userspace a sort of FAILFAST flag checkers 
could use.

I'm more than willing to get that problem straight in the tools, but 
what's the status on the kernel side of this work ?

We can also debate other ways to work-around this, if some emerge.


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 :

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@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].

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

Re: [RFC] 2 features for mptools 0.4.8

[Philip R. Auld]

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@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@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