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

[julian_satran@il.ibm.com]

We could add the RefCmdSN and it may help plug-in the hole but unless the
Abort is ussued on the same connection as the original command we can't be
sure that the old-one will not pop-up (as we enable ExpCmdSN to move on we
don't have even the 2**31-1 protection bracket :-)). Thus sending in
another nop/abort on the same connection is still required.

To simplify the whole process I will:

 a - add RefCmdSN to the Task Management
 b - add a command not received yet to the answers

 c - add a part to 7 reading:

1.1  How to Abort Safely a Command that Was Not Received

   To abort safely a task for which the task abort answer is "Command Not
   Received Yet" the initiator must issue another abort command on the same
   connection as the original command unless this connection was logged out
   in which case it may send it on any connection. The expected response
   for the second abort is Function Complete (if the command did not
   arrive) or "Task was not in task set".


   This convoluted scheme is necessary as the target does not know to what
   connection the hole is related and we don't want to force abort task to
   the same connection as the original command.


   Julo

Santosh Rao <santoshr@cup.hp.com> on 27/04/2001 20:46:53

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:   matt_wakeley@agilent.com
Subject:  Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery




Julian,

The conclusion on this thread was that some text was to be added to the
spec to address this issue. The rev 06 does not have any text to this
effect. It would help to explicitly describe how initiators should plug
the hole in CmdSN when they do not intend to use "command retry".

Also, regarding the use of NOP-OUT to fill the hole, why not just use
Abort Task for the same purpose ? Do we need a 2nd outbound PDU from the
initiator just to fill the hole ? When the initiator encounters a ULP
timeout, it would use an Abort Task to error the I/O. If the Abort Task
can contain the CmdSN of the original command being aborted, targets can
fill the hole based on that information, without requiring a second
outbound PDU from the initiator for this purpose.

Some text in the draft on this subject would be helpful to implementors.

- Santosh


julian_satran@il.ibm.com wrote:
>
> Santosh,
>
> You had a possible answer from Matt.  However I agree that we might want
> to address this in text



julian_satran@il.ibm.com wrote:
>
> I the hole is in the command queue and the task is just aborted the
> response to the abort task
> will unveil the fact that it did not reach destination.
>
> Initiator can recover from there in several ways - clear the task set,
fill
> the hole with an iSCSI noop etc.
> The latter, I recall, Was sugested to you by Matt Wakeley a while ago.
>
> None of them require any changes in the spec.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com> on 27/04/2001 04:56:26
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI : Bridging missing CmdSNs and Abort I/O Error
recovery
>
> Julian,
>
> Could you please clarify if the below issue is going to be addressed in
> the iSCSI draft, as was discussed earlier.
> (http://ips.pdl.cs.cmu.edu/mail/msg03155.html).
>
> Specifically, is the spec going to address the issue of how initiators
> can plug a hole in CmdSN sequence when they detect a ULP timeout and/or
> choose not to use "command retry".
>
> Regards,
> Santosh
>
> julian_satran@il.ibm.com wrote:
> >
> > Santosh,
> >
> > You had a possible answer from Matt.  However I agree that we might
want
> to
> > address this in text although
> > a solution similar to that suggested by Matt should be by now obvious
to
> > every implementer - the target should leave a placeholder in the input
> > queue until the command after gets delivered.
> >
> > Julo
> >
> > Santosh Rao <santoshr@cup.hp.com> on 25/01/2001 21:38:04
> >
> > Please respond to Santosh Rao <santoshr@cup.hp.com>
> >
> > To:   IPS Reflector <ips@ece.cmu.edu>
> > cc:
> > Subject:  iSCSI : Bridging missing CmdSNs and Abort I/O Error recovery
> >
> > 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
> >
> >  - santoshr.vcf
>  - santoshr.vcf
 - santoshr.vcf