Re: iSCSI: draft 7: iSCSI response and SCSI sense data

["Jim Hafner" <hafner@almaden.ibm.com>]

Rob,

I agree with you.  These layering violations (and some of the others you've
also noted on the reflector) should be removed from the draft.

Jim Hafner


"Elliott, Robert" <Robert.Elliott@compaq.com>@ece.cmu.edu on 08-01-2001
04:26:57 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: draft 7: iSCSI response and SCSI sense data



iSCSI draft 7 section 2.4.3 includes a table relating the iSCSI
response codes to various CHECK CONDITION status additional
sense codes:

  "0x01 Target Failure
    ASC=0x44 ASCQ=0x00 INTERNAL TARGET FAILURE
  0x02 Delivery Subsystem Failure
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED
  0x03 Unsolicited data rejected
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x04 Not enough unsolicited [data]
    ASC=0x49 ASCQ=0x00 INVALID MESSAGE ERROR
  0x05 SNACK rejected [Command in progress]
    ASC=0x47 ASCQ=0x03 INFORMATION UNIT CRC ERROR DETECTED

  As listed above, each defined response code MUST be used (under the
  conditions described in the 'Reason' field), only when the
  corresponding SCSI CHECK CONDITION is signaled, to convey additional
  protocol service information.  A SCSI CHECK CONDITION with the ASC
  and ASCQ values as tabulated MUST be signaled by iSCSI targets for
  all the instances in this document referring to usage of one of the
  above defined response codes."

No other SCSI protocol does this. iSCSI seems to be granting the
SCSI-level status a priority over the iSCSI-level response data.
I think the other protocols treat the response data as more
important; if the response data indicates a problem, the SCSI layer
is considered broken and the SCSI status is undefined.

Forcing the iSCSI layer to fill in those fields seems to break the
layering model.

I suggest removing the CHECK CONDITION status and additional sense
code linkage and leave the SCSI status undefined if the iSCSI
response is nonzero.

This is compatible with SAM-2, which only requires status be returned
when the service response is TASK COMPLETE (SAM-2 revision 18
section 5.3.1):
  "Status shall be sent from the logical unit to the application
   client whenever a command ends with a service response of
   TASK COMPLETE or LINKED COMMAND COMPLETE."

Furthermore, SAM-2 requires that status be ignored when the service
response indicates an error (SAM-2 revision 18 section 5.1):
  "Status: A one-byte field containing command completion status
  (see 5.3). If the command ends with a service response of
  SERVICE DELIVERY OR TARGET FAILURE, the application client
  shall consider this parameter to be undefined."

I think iSCSI's current wording may violate this rule.
---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com