Re: [RFC] [Last Rites] fc transport: extensions for fast fail and dev loss

[James Smart <James.Smart@Emulex.Com>]

Christoph Hellwig wrote:
>>   at (b): Minimally, we should terminate all active i/o requests marked
>>           as type REQ_FASTFAIL. From an api perspective, driver support
>>           for this is optional. And we must also assume that there will
>>           be implementations which have to abort all i/o in order to
>>           terminate those marked REQ_FASTFAIL. Is this acceptable ?
>>           (it meets the "always" condition above)
>>
>>           Q: so far we've limited the io to those w/ REQ_FASTFAIL.
>>             Would we ever want to allow a user to fast fail all i/o
>>             regardless of the request flags ? (in case they flags
>>             weren't getting set on all the i/o the user wanted to
>>             see fail ?)
> 
> I think we should fail all.  It's not like an unprivilegued process could
> request FASTFAIL.  The administrator should know what she/he is doing.

Good.  All it is.

>>> - fast_loss_time recommendation:
>>>  In discussing how a admin should set dev_loss_tmo in a multipathing
>>>  environment, it became apparent that we expected the admin to know
>>>  a lot. They had to know the transport type, what the minimum setting
>>>  can be that still survives normal link bouncing, and they may even
>>>  have to know about device specifics.  For iSCSI, the proper loss time
>>>  may vary widely from session to session.
>>>
>>>  This attribute is an exported "recommendation" by the LLDD and transport
>>>  on what the lowest setting for dev_loss_tmo should be for a multipathing
>>>  environment. Thus, the admin only needs to cat this attribute to obtain
>>>  the value to echo into dev_loss_tmo.
>> The only objection was from Christoph - wanting a utility to get/set this
>> stuff. However, the counter was this attribute was still meaningful, as it
>> was the conduit to obtain a recommendation from the transport/LLD.
>>
>> So - I assume this proceeds as is - with a change in it's description.
> 
> I must say I'm still not happy with this.  It's really policy that we
> try to keep out of the kernel.

Ok. I'll drop this. I don't think it was that important for FC. Mike Christie
had some better arguments for iSCSI.

-- james