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

["Dev" <deva@stargateip.com>]

Robert,

I agree with you fully on this.  

---
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.

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

------

Thanks

Deva
Platys Communications

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Elliott, Robert
Sent: Wednesday, August 01, 2001 4:27 PM
To: 'ips@ece.cmu.edu'
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