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

From: "Julian Satran" <[email-masked]>
Date: Thu, 14 Mar 2002 23:13:24 +0200

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                                                                        
                      <[email-masked]>          To:       Julian Satran/Haifa/IBM@IBMIL                   
                                               cc:       [email-masked]                                 
                      14-03-02 16:55           Subject:  Re: ISCSI: need to fix handling of partial data 
                      Please respond to         transfers                                                
                      Paul Koning                                                                        

>>>>> "Julian" == Julian Satran <[email-masked]> 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

---

From: Paul Koning <[email-masked]>
Date: Fri, 15 Mar 2002 09:52:53 -0500

>>>>> "Julian" == Julian Satran <[email-masked]> 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