Re: iSCSI: DataRN

[Matt Wakeley <matt_wakeley@agilent.com>]

Julian,

The current draft says:

1.2.2.2 Response/Status numbering

Responses in transit from the target to the initiator are numbered.
...
Initiators and Targets MUST support the response-numbering scheme
regardless of the support for command recovery.

The words "are numbered" and "MUST support" don't sound like "should" to me...

-Matt

julian_satran@il.ibm.com wrote:
> 
> Santosh,
> 
> The current draft has status numbering as SHOULD and that is (as it was
> pointed out to me) almost mandatory.
> Considering that the consensus at Orlando and on the list was to make CmdRN
> (now CmdSN) mandatory even for one connection I don't see any reason not to
> make StatSN support also mandatory .
> 
> On Writes our assumptions was that the target can at any point in time
> either reject the restart (if as you outline it can't do it) or if it can
> reacquire the data it misses trough R2T and resend the status (on writes
> the target is assumed to know what it needs). In case it rejects the
> restart you can report a "transport failure" and you are as good as a
> parallel packetized SCSI.
> 
> Julo
> 
> Santosh Rao <santoshr@cup.hp.com> on 25/01/2001 00:13:53
> 
> Please respond to Santosh Rao <santoshr@cup.hp.com>
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: DataRN
> 
> julian_satran@il.ibm.com wrote:
> 
> > 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".
> 
> 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.
> 
> >    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)
> 
> 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
> 
>  - santoshr.vcf