SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    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
    
    


Home

Last updated: Tue Sep 04 01:04:07 2001
6315 messages in chronological order