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



    
    Paul,
    
    We have different opinions on basics.
    If I enter into an appliance shop and ask for a bottle of milk - I get an
    "error message".
    It may fall in one of two categories:
    
       "protocol error" (in humanes - "you are an idiot")
       "we don't keep milk"
    
    
    I agreed that the first was not nice and I will change it.
    But there are errors from which you have no recovery - the devices can't
    work with each other.
    
    Julo
    
    
                                                                                                   
                          Paul Koning                                                              
                          <ni1d@arrl.net>          To:       Julian Satran/Haifa/IBM@IBMIL         
                                                   cc:       ips@ece.cmu.edu                       
                          15-03-02 16:52           Subject:  Re: ISCSI: need to fix handling of    
                          Please respond to         partial data transfers                         
                          Paul Koning                                                              
                                                                                                   
                                                                                                   
    
    
    
    >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
    
     Julian> Paul, You has two sets of counters - block counters in the
     Julian> CDB and byte counters in the execute command.  That is enough
     Julian> evidence I think and some time both block and byte in
     Julian> extended CDBs.
    
    But both describe the command as a whole.  We were talking about the
    piece-wise data transfers that occur during the execution of the
    command.  If the target requests size X, can the initiator send < X?
    
    I don't see SAM-2 allowing for that.  But since it's just talking
    about architectural models, perhaps it doesn't really matter.
    
     Julian> As for announcing at login - this is not good enough as this
     Julian> capability may also vary per LUN and/or command.
    
    Yes, I suppose so.  That assumes, of course, that it makes sense to
    build an initiator that can't comply with any data length a target can
    legitimately ask for.  I'm not sure why anyone would build such an
    initiator.
    
    This leaves us with a problem.  If the target requests X, the
    initiator sends < X, and the target objects, what next?  What is the
    recovery algorithm?  Is there a recovery algorithm?
    
    One possible recovery algorithm is: the initiator gets the error code,
    recognizes it should have sent exactly X, and does so.  But if it can
    do that, it should have sent exactly X the first time around.
    
    Another possibility is that the initiator is completely unable to send
    exactly X.  At that point, it seems that the only thing it can do is
    to fail the I/O operation.  In that case, it might as well have done
    that the first time around, when it was asked to send X and realized
    it could not comply.
    
    An error message response to an exchange is useful only if it permits
    a meaningful recovery action.  I may be missing something, but I don't
    see a way that the error message gives you any new capability.  The
    situation is no better than it would be if you use the rule "you must
    send exactly X if the target asks for X".  That rule is much simpler
    than the rule currently in the spec, and it eliminates the confusing
    possibility of mismatched expectations between the two sides.
    
    If there is a more elegant recovery than what I described above, what
    is it?  The spec may need to document what that would be.
    
       paul
    
    
    
    
    
    


Home

Last updated: Sat Mar 16 12:18:07 2002
9156 messages in chronological order