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

From: Santosh Rao <[email-masked]>
Date: Thu, 26 Apr 2001 18:56:26 -0700

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

[email-masked] 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 <[email-masked]> on 25/01/2001 21:38:04
> 
> Please respond to Santosh Rao <[email-masked]>
> 
> To:   IPS Reflector <[email-masked]>
> 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