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

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

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