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

[Hannes Reinecke]

Hi Mike,

Mike Christie wrote:
> 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.
> 
Indeed, I didn't look closely enough. Ok, so I/O will be failed after
terminate_rport_io. 

So that means we can just implement a new netlink message after
terminate_rport_io to inform the multipath daemon about this changes.

And, of course, we _really_ should introduce a new sdev state here.
Having the sdev set to 'RUNNING' but having all I/O failed in the
transport class is just a quirky behaviour which is bound to cause
trouble.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)