SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Data in SCSI Response or SCSI Data



    Douglas Otis wrote:
    
    > > > then it should send a response structure as FCP and not one or two and
    > > > use it according to FCP.  Undefined information of what some
    > > consider SCSI
    > > > values cause variants in use.  I have not seen tape drives use
    > > Good Sense
    > > > residual but vary in how Check Sense residual is presented.  If
    > > iSCSI is to
    > > > copy FC, then why deviate on response symmetry?  At least this
    > > provides an
    > > > easier bridge.  Iterative read operations will carry unused values to be
    > > > examined and opens the door for further variants.  Status
    > > presented prior to
    > > > data must then ensure sequence without end confirmation.
    > >
    > > Who said anything that status was presented before data?
    > > iSCSI allows the LAST iSCSI PDU that completes a SCSI command to
    > > also contain
    > > the GOOD SCSI status in the header, so that extra overhead to
    > > send the status
    > > PDU.
    >
    > By placing status within the header of perhaps 4G of data payload with no
    > defined end structure leaves nothing known to follow this transfer.  By
    > making Response a separate structure that physically follows the data
    > payload there is an end confirmation.  Should there be an error in sequence,
    > data will be accepted followed by perhaps some unknown command responses
    > until everything falls back into sync.  A dubious savings having dummy
    > status in each read exchange to save one possible structure at the end.
    > Rather than processing one response structure, you must process two where
    > one is out of sequence to the function.
    >
    > Doug
    
    Doug, this is TCP - a guaranteed byte stream.  If the target successfully reads
    4G of data off its media into cache memory, and transmits it as one iSCSI
    message, TCP will deliver the data/message.  If TCP fails for some reason to
    deliver the message (and everything after it), then the initiator knows because
    the number of bytes read from TCP do not match the length of the iSCSI message
    (indicated in the header).  Now, if the header also indicates good status (as
    read from the target media into target cache), what's the big deal that its in
    the header as opposed to a separate message after the data iSCSI message?
    
    -Matt
    
    


Home

Last updated: Tue Sep 04 01:07:26 2001
6315 messages in chronological order