Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery

[Matt Wakeley <matt_wakeley@agilent.com>]

The target iSCSI is the only entity that has knowledge of CmdSN.  When it
receives a commands, it delivers them to the SCSI layer in CmdSN order (with
the CmdSN stripped off).  iSCSI does not handle the abort commands.

If an I/O times out (because of a connection failure) and is aborted by the
upper level driver such that it is dequeued from the iSCSI driver (and
therefore cannot be retransmitted on a new connection), then the iSCSI driver
can simply send a NOP command in it's place.

-Matt

Santosh Rao wrote:
> 
> Julian & All,
> 
> The draft is currently lacking a section that addresses abort I/O error
> recovery. Specifically, how is CmdSN bridging issues to be handled in
> the case where an initiator chooses not to retry an I/O [that failed on
> a connection failure that affects the delivery of the command to the
> target or a digest error at the target] because its ULP timer may have
> expired.
> 
> In such cases, the initiator can send an Abort Task to inform the target
> that the I.T.T is being aborted and its corresponding CmdSN can be
> bridged, instead of having the target stall infinitely in its attempt to
> enforce ordering and await the missing CmdSN [which is'nt going to
> arrive, because the initiator did not retry the command].
> 
> Regards,
> Santosh