[dm-devel] [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 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].

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