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



    >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
    
     Julian> I was under the impression that all over SCSI an initiator
     Julian> sending less data than requested by a target is tolerable.
     Julian> from a SCSI point if view but it is not always tolerable at
     Julian> device level. 
    
    I'm not sure that this is true.  Looking at the SCSI specs for
    guidance, I find a few words on this topic in SAM-2 (section 5.4.3,
    "Data transfer protocol services").  This mentions as one of the
    transfer parameters "Byte count requested by device server: number of
    bytes to be moved by the data transfer request".  It doesn't say
    "maximum number of bytes...".  Also, the confirmation primitives for
    the Send Data-In and Receive Data-Out primitives both indicate
    completion, but do not indicate an actual byte count, which again
    suggests that the actual byte count is supposed to match the requested
    byte count.
    
     Julian> I will change the wording to better convey
     Julian> this - i.e. choosing another error code for failing on the
     Julian> FirstBurstSize and not meeting the Desired Data Length ( "Not
     Julian> Enough Data" instead of "Protocol Error") and attach the
     Julian> corresponding SCSI error status and sense (as we did with
     Julian> data errors).  Is this acceptable?
    
    It's better than what we have now, because the status code you
    proposed no longer implies that there's a bug in the implementation.
    
    I still don't like it much.  It's very ugly to have options in the
    protocol where, in the middle of a long session, you suddenly get a
    reject from the other side because you did something the protocol
    allows that the other end doesn't support (and is allowed not to
    support). 
    
    It would be far better to resolve this one way or the other and take
    away the unnecessary interoperability failures.  So I much prefer
    either to require the initiator to do exactly what the target asked
    for (as implied by SAM-2) or, failing that, to require the target to
    accept shorter responses from the initiator -- as I proposed before.
    
    But if we're going to use this third approach, which is to leave in
    the option to reject, it would be much better if that is announced at
    login so the initiator will know what the target wants, and can adjust
    what it sends accordingly -- or can abandon the login if it is unable
    to comply with the target's requirements.
    
         paul
    
    


Home

Last updated: Fri Mar 15 06:18:12 2002
9132 messages in chronological order