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

[Paul Koning <ni1d@arrl.net>]

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