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

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

Michael Reed wrote:

> Haven't most drivers / board firmware generally cleaned up any outstanding
> i/o at the time (or shortly thereafter) of the fc_remote_port_delete()
> call?  I would think it reasonable to just require that the driver clean
> up the i/o after calling fc_remote_port_delete().  Is there a significant
> reason to keep the i/o alive in the driver?  The rport has just been
> deleted....  Would this eliminate the need for the callback?  If the
> driver implements this, could it just have a NULL callback routine?

You don't want to kill i/o at the time that the rport loses
connectivity (e.g. when we call delete). The biggest reason is for devices
that support FCP Recovery (Tape being a prime example, but it's not limited
to them). There are also several topology glitches, which can be seconds
in length, which are abberant, and really didn't reflect true device loss.
Why kill and reissue these io's as well ? it really just adds more load to
the system to abort and retry the i/o's.  Also, FC-DA compliance is
recommending that the login and the exchanges stay around as long as
possible (you could argue the diagram mandates it). So, for the best
"FC behavior" you really shouldn't kill the i/o until dev_loss_tmo fires.

-- james s

PS: I think you're highlighting my complaint with the patch. I should
  be renaming the "delete" function as it really isn't delete. The rport
  isn't truly "deleted" until dev_loss_tmo fires.  We didn't consider
  this when we dropped the block/unblock_rport routines in favor of the
  more straight-forward add/delete calls. At this point, I'd rather
  document the lifetime in the api/header than deal with namechanges and
  its affects on drivers/distros.