Subject: Re: iSCSI: DataRN

From: [email-masked]
Date: Wed, 24 Jan 2001 15:14:43 +0200

Santosh,

The ACK for a response is when status is ACKed (by the status numbering).

Before this ack a target has several options for restart:

   to keep all the data (recall we have dropped DataRN) and "restart
   sending".
   not to keep data and reject the command restart with a service response
   (that we have to specify) of restart reject (your tape target may want
   to do just this)
Alternatively we may want in the restart to indicate the phase the command
was in (Data Transfer or Status) and to let the target react accordingly
but I am not sure it is worth the effort.

Regards,
Julo

Santosh Rao <[email-masked]> on 23/01/2001 20:56:34

Please respond to Santosh Rao <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI: DataRN

[email-masked] wrote:

>
> The above is correct if the digest error or connection failure occurred
on
> delivery of the command. If a digest error were to be detected by an
> initiator on the response PDU (by which time the target has already
> completed the operation and the TCP layer at the initiator has already
> sent the ACK), then, the command is complete from the device perspective
> and should not be retried.
>
> <js> how would that happen ? </js>

Julian,

If the initiator detected a digest error on the Response PDU[and the target
has completed all or part of the data phase], such an operation cannot be
retried without a prior rewind command, in the case of sequential media.

The iSCSI layer cannot retry commands destined to sequential media when
there
is a possibility that some or all of the data phase is complete.

Regards,
Santosh

 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Wed, 24 Jan 2001 14:13:53 -0800

>    to keep all the data (recall we have dropped DataRN) and "restart

This may work for a READ if the iSCSI layer has buffered the data until it
gets a StatSN ACK. Note that even for the READ, status recovery is optional
and a tape may not implement status / data recovery and just retry the
command. In such a case, a retry results in the target re-doing the operation.

For a WRITE however, I don't see how this is going to work. Are you suggesting
that the iSCSI layer NOT deliver data to the SCSI layer until the Response is
acknowleged ??? This is ruled out, since the Response itself comes from the
SCSI layer upon completion of the SCSI command.

If, on the WRITE, the data was delivered to the SCSI layer which then wrote it
to media and advanced the tape, what good does the above do ?? The tape has
advanced following the WRITE and the initiator can corrupt the tape by
retrying the WRITE.

>    (that we have to specify) of restart reject (your tape target may want

You seem to suggest moving the responsibility of ensuring data integrity from
the host to the target !! This is not suitable for the following reasons :
a) Often, tape is the last class of storage products to migrate to new storage
transport technologies. IOW, the majority of tape backup is going to attain
iSCSI connectivity through a iSCSI-FC bridge or iSCS-pSCSI bridge. In such a
case, the service response management is done in the bridge and this level of
intelligence is now being moved into the bridge.

The responsiblity of ensuring data integrity on a SCSI target lies with the
initiator issuing the I/O.

iSCSI MUST not retry a command to sequential media when there is the
possiblity that some or all of the data phase has completed.

Regards,
Santosh