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

["Mallikarjun C." <cbm@rose.hp.com>]

Robert and all,

As the one who suggested that wording into the draft, let me 
add some comments. (Please see
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html
for my initial proposal.)

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

I agree, as Steph already alluded to in a separate email, the ideal 
solution appears to: 
          a) drop the response code *definitions* (ie. leave
             room for vendor-unique codes) altogether, and
          b) continue to specify the right SCSI CHECK CONDITION 
             (ASC, ASCQ) values for the iSCSI error events (such
             as digest failures).

As I said in the earlier referenced message "mandate a standard 
SCSI CHECK CONDITION on these errors with the current response codes 
acting as detailed descriptions.".  But you bring up a good point 
that this "detailed descriptions" may be violating SAM-2's expectations. 

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

I disagree.  If the affected SCSI task can be reliably ascertained
by the target, it appears highly desirable to report the status 
using a SCSI CHECK CONDITION.  Target iSCSI layer has to internally
terminate the pre-instantiated SCSI task anyway informing its SCSI 
layer of the fact.  Besides, there are precedents in FCP-2 for similar
cases where the task is identifiable.

Regards.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com

"Elliott, Robert" wrote:
> 
> 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