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

["Julian Satran" <Julian_Satran@il.ibm.com>]

Paul,

You has two sets of counters - block counters in the CDB and byte counters
in the execute command.
That is enough evidence I think and some time both block and byte in
extended CDBs.

As for announcing at login - this is not good enough as this capability may
also vary per LUN and/or command.

Julo


                                                                                                         
                      Paul Koning                                                                        
                      <ni1d@arrl.net>          To:       Julian Satran/Haifa/IBM@IBMIL                   
                                               cc:       ips@ece.cmu.edu                                 
                      14-03-02 16:55           Subject:  Re: ISCSI: need to fix handling of partial data 
                      Please respond to         transfers                                                
                      Paul Koning                                                                        
                                                                                                         
                                                                                                         



>>>>> "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