Re: LSF: Multipathing and path checking question

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

 



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@xxxxxxx			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux