|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI : Initiators expected to fake CHECK CONDITIONS.Julian, This seems like the zillionth time aired this same disagreement. I think we should try to reach a WG consensus on whether iSCSI should use SCSI status as a means for reporting protocol-related errors, and kill it once and for all. I'm strongly against it. > And an error in the iSCSI layer gets reported by the next layer - that is > the regular layering technique (and BTW I am getting a bit uneasy about all > this preaching on layering when it is not obvious that you understand all > the implications of the point). Santosh seems to understand 100%. I agree with Santosh. SAM defines three pieces of status returned by Execute Command() (which is, in turn implemented by each SCSI protocol, e.g. iSCSI): 1) Service Response: task complete, linked command complete, service delivery or target failure. 2) SCSI status byte 3) SCSI sense data SAM clearly suggest that a protocol's means for signalling protocol-detected errors is the service response status when it says: The actual protocol events corresponding to a response of TASK COMPLETE, LINKED COMMAND COMPLETE or SERVICE DELIVERY OR TARGET FAILURE shall be specified in each protocol standard. Note that defining protocol error events in terms of TC, LCC, SDF and TF, remains an abstraction. An actual implementation can chose to signal these events by whatever means. All SCSI implementations I've seen do have a status return component which exactly corresponds to SAM's service response status, but has more than just these four alternatives. Typically, that includes things like success, command timeout, addressing failure (selection timeout in ||SCSI, bad AL_PA in FCAL, etc.), command aborted, bus parity error, etc.. What iSCSI does need to do is clearly define its error events AS protocol events, which is what describing them in terms of the SAM specified set does. ||SCSI, FCP and the other SCSI protocol standards do this. Operationally, this means that in iSCSI: o protocol-specific errors for a task detected by the target without a CLEARLY corresponding SCSI error return should be signalled using the iSCSI response mechanism. The initiator will handle these errors by recording them in some appropriate way, and selecting an appropriate service response status value. o errors for a task detected directly by the initiator are handled by recording them in some appropriate way, and selecting an appropriate service response status value. I don't know that there's a single sentence or section in SAM which says this, but it clearly implies that the components of SCSI status (status byte and sense) are data which are CARRIED (not created) by SCSI protocols, for the use of the protocol-independent components. For example, a disk peripheral driver reacts to SCSI status and sense generated by disks for SCSI operations that it starts. SCSI status should be equivalent to the SCSI status returned by the logical unit. SCSI protocols are not citizens of the SCSI status space, which means that the real citizens (the command standards, and SAM), may define semantics of SCSI error codes which conflict with iSCSI's selections. The `hardware error' sense key might be defined to mean something very specific within a particular SCSI peripheral command set, and your choice of synthesizing SCSI status within the protocol could cause this behavior to misfire. > [js} the error was generated by a faulty controller and I did not find > any other SCSI sense fit for it[/js] That's because there IS no SCSI sense fit for it. It is a protocol-detected, protocol-unique error. Therefore it should be signalled using the service response status. Steph
Home Last updated: Tue Sep 04 01:05:51 2001 6315 messages in chronological order |