SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: DataRN



    
    
    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
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:44 2001
6315 messages in chronological order