|
[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> 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
Home Last updated: Sat Mar 16 08:18:15 2002 9148 messages in chronological order |