[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] [RFC] 2 features for mptools 0.4.8



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]