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

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

Michael Reed wrote:
> In thinking about this over night, I would like to withdraw my previous
> comments.  (Hence the snip!)
> 
> Let's take the case of real time capture from a device and
> post processing of that data.  The capture operation would
> likely want a fast fail to avoid dropping data.  The post
> processing of that data would like to wait for the device
> to return to avoid disruption and potential premature termination
> of the job.
> 
> Under the above scenario, assuming it's a valid scenario, are there
> mechanisms in place to allow an application to tag an i/o stream
> for fast fail?

Two comments:
- This conflicts with Christoph's last comment about fast_fail failing all
   i/o's. I prefer the fail all, as its the easier, more straight-forward
   approach. Easiest to explain behavior for too.
- As for tagging i/o from an application, the only places I see in the
   kernel setting the flags that make REQ_FAILFAST get set are strictly
   in-the-kernel items (multipath). I don't see any way for an application
   to mark this.  It implies that to do what you stated above, requires the
   app has to serially perform each mode - and to do so at a target level.
   E.g. set fast fail, perform capture, set no fast fail, perform post
   processing.

-- james s