SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    remove



    
    
    -----Original Message-----
    From: Eddy Quicksall [mailto:ESQuicksall@hotmail.com]
    Sent: Monday, August 06, 2001 2:23 PM
    To: Elliott, Robert; ips@ece.cmu.edu
    Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
    
    
    Then what was the purpose of giving them separate fields and eliminating
    the
    S bit?
    
    Eddy
    
    ----- Original Message -----
    From: "Elliott, Robert" <Robert.Elliott@compaq.com>
    To: <ips@ece.cmu.edu>
    Sent: Thursday, August 02, 2001 6:04 PM
    Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
    
    
    > My view:
    > If a non-zero response code is present, the Status field is undefined
    > and the response data contains all information about the error (fed
    > from the iSCSI layer).
    >
    > If the target is capable of reporting a Status, then the response
    > field is zero and the sense data contains all information about the
    > error (fed from the SCSI layer, which might communicate with the
    > iSCSI layer internally to figure out some of the information).
    >
    > ---
    > Rob Elliott, Compaq Server Storage
    > Robert.Elliott@compaq.com
    >
    >
    >
    > > -----Original Message-----
    > > From: Robert Snively [mailto:rsnively@brocade.com]
    > > Sent: Thursday, August 02, 2001 4:39 PM
    > > To: 'cbm@rose.hp.com'; Elliott, Robert
    > > Cc: 'ips@ece.cmu.edu'
    > > Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data
    > >
    > >
    > > I am not sure that complete removal of the response codes
    > > is the best approach.  There are some things
    > > that SCSI devices can know nothing about, and only TCP links
    > > can know about.  There are other things that iSCSI state machines
    > > know about that logical units do not know about (usually software
    > > generated inconsistencies in the protocol procedures).  These are
    > > natural candidates for response codes.  Note that vendor
    > > specific is a synonym for non-interoperable and also for
    > > undesirable.  It is far better to reserve anything like that,
    > > since the behavior in the presence of a vendor specific value
    > > is not defined.  While it is clear that may response codes should
    > > move over to CHECK CONDITIONS, I think that there are
    > > still some protocol related response codes that will be required.
    > >
    > > Bob
    > >
    > > -----Original Message-----
    > > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
    > > Sent: Wednesday, August 01, 2001 9:06 PM
    > > To: Elliott, Robert
    > > Cc: 'ips@ece.cmu.edu'
    > > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
    > >
    > >
    > > 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
    > >
    >
    


Home

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