[dm-devel] LSF: Multipathing and path checking question
Mike Christie
michaelc at cs.wisc.edu
Mon Apr 20 19:28:23 UTC 2009
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 at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the dm-devel
mailing list