[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