SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: ISCSI: need to fix handling of partial data transfers



    I was under the impression that all over SCSI an initiator sending less
    data than requested by a target is tolerable.
    from a SCSI point if view but it is not always tolerable at device level.
    I will change the wording to better convey this - i.e. choosing another
    error code for failing on the FirstBurstSize and not meeting the Desired
    Data Length ( "Not Enough Data" instead of "Protocol Error") and attach the
    corresponding SCSI error status and sense (as we did with data errors).
    Is this acceptable?
    
    Julo
    
    
                                                                                                            
                          Paul Koning                                                                       
                          <ni1d@arrl.net>          To:       ips@ece.cmu.edu                                
                          Sent by:                 cc:                                                      
                          owner-ips@ece.cmu        Subject:  ISCSI: need to fix handling of partial data    
                          .edu                      transfers                                               
                                                                                                            
                                                                                                            
                          13-03-02 19:11                                                                    
                          Please respond to                                                                 
                          Paul Koning                                                                       
                                                                                                            
                                                                                                            
    
    
    
    Here's a point I mentioned before, but it got mixed up in the debate
    over the "PDU sector alignment" proposal and wasn't resolved.  So here
    it is again, standalone.
    
    There are several places in the protocol where one end specifies a
    quantity of data that it would like to see.  Currently, the spec
    allows the amount of data transfered to be less than what was asked
    for, BUT it also allows the recipient of that data to complain
    ("Protocol error") if what is received is less than what was asked
    for.
    
    In other words, the spec explicitly allows conforming implementations
    that do not interoperate.
    
    I do not believe this makes any sense.  Failure to interoperate due to
    an implementation bug I can understand: if that happens you fix the
    code.  But it is not at all reasonable for the spec to permit one end
    to send a sequence of protocol messages, and then permit the other end
    to reply to that CONFORMING sequence with the reply "Protocol error".
    
    In particular:
    
    R2T specifies Desired Data Transfer Length.  Section 9.8 allows the
    initiator to reply with less than that amount, and it then allows the
    target to call that a protocol error.
    
    Similarly, section 9.3.5 allows an initiator to send less than
    FirstBurstSize unsolicited data even when the total transfer length is
    more than that, yet it allows the target to reject such transfers.
    
    These need to be changed.  There are two possible fixes:
    
    1. Tighten up the initiator rules to require the initiator to send
    precisely the requested amount (i.e., Desired Data Transfer Length in
    response to R2T, and the negotiated FirstBurstSize as unsolicited
    data) rather than an arbitrary amount <= that amount.  In other words,
    in the 4th paragraph of 9.3.5 change "SHOULD" to "MUST"; in the 3rd
    paragraph of 9.8  change "MUST not exceed" to "MUST exactly equal" and
    before "If the last PDU..." insert "The total amount of data sent by
    the initiator must exactly equal the Desired Data Transfer Length."
    
    2. Alternatively, tighten up the target rules, requiring the target to
    accept as valid and correct transfers less than the amount requested.
    In other words, in the 4th paragraph of 9.3.5 replace the last
    sentence by "The target MUST accept a command for which the Expected
    Data Transfer Length is higher than the FirstBurstSize and for which
    the initiator sent less than the FirstBurstSize unsolicited data."; in
    the 3rd paragraph of 9.8 change "If the last PDU..." to "If the last
    PDU (marked with the F bit) is received before the Desired Data
    Transfer Length is transferred, a target MUST accept that as a valid
    response to the R2T PDU."
    
    On grounds of simplicity I prefer solution 1, but I can support either
    as a valid fix of the current problem.
    
        paul
    
    
    
    
    
    


Home

Last updated: Thu Mar 14 10:18:15 2002
9118 messages in chronological order