Re: [dm-devel] LSF: Multipathing and path checking question

[Mike Christie <michaelc@cs.wisc.edu>]

Mike Christie wrote:
> Hannes Reinecke wrote:
>>> Today, instead of #2, the Red Hat multipath tools guy and I were talking
>>> about doing a probe with SG_IO. For example we would send down a path
>>> tester IO and then wait for it to be failed with DID_TRANSPORT_FAILFAST.
>>>
>> No. this is exactly what you cannot do. SG_IO will be stalled when the
>> sdev is BLOCKED and will only return a result _after_ the sdev 
>> transitions
>> _out_ of the BLOCKED state.
>> Translated to FC this means that whenever dev_loss_tmo is _active_ (!)
>> no I/O will be send out neither any I/O result will be returned to 
>> userland.
>>
> 
> That is not true anymore. When fast io fail fires, the sdev and rport 
> will be blocked, but the the fc class will call into the LLD to have it 

I miswrote that. The rport will be show blocked state, but when fast io 
fail tmo fires, fc_terminate_rport_io will unblock the sdev, and the fc 
class chkready will fail any IO sent to it and of course 
terminate_rport_io will fail IO in the driver like I said below. And 
then you do not need a terminate_rport_io callback to have the fast io 
fail tmo now. If you set that timer at least IO in the block queue and 
new IO will be failed.


> fail any IO still running in the driver. The FC class will then fail any 
> IO in the block queues, and then it will also fail any new IO sent to it.
> 
> With your patch to have multipath-tools set fast io fail for multipath, 
> then we should always get the IO failed before dev_loss_tmo fires.
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html