|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: ISCSI: need to fix handling of partial data transfersI was under the impression that all over SCSI an initiator sending less data than requested by a target is tolerable. from a SCSI point if view but it is not always tolerable at device level. I will change the wording to better convey this - i.e. choosing another error code for failing on the FirstBurstSize and not meeting the Desired Data Length ( "Not Enough Data" instead of "Protocol Error") and attach the corresponding SCSI error status and sense (as we did with data errors). Is this acceptable? Julo Paul Koning <ni1d@arrl.net> To: ips@ece.cmu.edu Sent by: cc: owner-ips@ece.cmu Subject: ISCSI: need to fix handling of partial data .edu transfers 13-03-02 19:11 Please respond to Paul Koning Here's a point I mentioned before, but it got mixed up in the debate over the "PDU sector alignment" proposal and wasn't resolved. So here it is again, standalone. There are several places in the protocol where one end specifies a quantity of data that it would like to see. Currently, the spec allows the amount of data transfered to be less than what was asked for, BUT it also allows the recipient of that data to complain ("Protocol error") if what is received is less than what was asked for. In other words, the spec explicitly allows conforming implementations that do not interoperate. I do not believe this makes any sense. Failure to interoperate due to an implementation bug I can understand: if that happens you fix the code. But it is not at all reasonable for the spec to permit one end to send a sequence of protocol messages, and then permit the other end to reply to that CONFORMING sequence with the reply "Protocol error". In particular: R2T specifies Desired Data Transfer Length. Section 9.8 allows the initiator to reply with less than that amount, and it then allows the target to call that a protocol error. Similarly, section 9.3.5 allows an initiator to send less than FirstBurstSize unsolicited data even when the total transfer length is more than that, yet it allows the target to reject such transfers. These need to be changed. There are two possible fixes: 1. Tighten up the initiator rules to require the initiator to send precisely the requested amount (i.e., Desired Data Transfer Length in response to R2T, and the negotiated FirstBurstSize as unsolicited data) rather than an arbitrary amount <= that amount. In other words, in the 4th paragraph of 9.3.5 change "SHOULD" to "MUST"; in the 3rd paragraph of 9.8 change "MUST not exceed" to "MUST exactly equal" and before "If the last PDU..." insert "The total amount of data sent by the initiator must exactly equal the Desired Data Transfer Length." 2. Alternatively, tighten up the target rules, requiring the target to accept as valid and correct transfers less than the amount requested. In other words, in the 4th paragraph of 9.3.5 replace the last sentence by "The target MUST accept a command for which the Expected Data Transfer Length is higher than the FirstBurstSize and for which the initiator sent less than the FirstBurstSize unsolicited data."; in the 3rd paragraph of 9.8 change "If the last PDU..." to "If the last PDU (marked with the F bit) is received before the Desired Data Transfer Length is transferred, a target MUST accept that as a valid response to the R2T PDU." On grounds of simplicity I prefer solution 1, but I can support either as a valid fix of the current problem. paul
Home Last updated: Thu Mar 14 10:18:15 2002 9118 messages in chronological order |