Re: remove

["Julian Satran" <Julian_Satran@il.ibm.com>]

An additional qualifier (iSCSI) for bad status.  Julo

"Tim Arland" <tim.arland@aebs.com>@ece.cmu.edu on 06-08-2001 23:48:29

Please respond to "Tim Arland" <tim.arland@aebs.com>

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


To:   "Eddy Quicksall" <ESQuicksall@hotmail.com>, "Elliott, Robert"
      <Robert.Elliott@compaq.com>, <ips@ece.cmu.edu>
cc:
Subject:  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
> >
>