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

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

David,

It appears to me that generating a SCSI CHECK CONDITION is
the right thing for iSCSI to do regardless of T10's eventual
decision (ACA/persistent-UA (T10 proposal 00-359r1)/something
totally different) on a mechanism to enforce ordering semantics.

Robert Elliott pointed out a violation by iSCSI in trying to 
additionally qualify ASC, ASCQ with its response codes.  I suggest 
that dropping this "additional description" attempt in all these 
cases is all iSCSI needs to do to meet SAM's expectations.

Regards.
-- 
Mallikarjun 

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


Black_David@emc.com wrote:
> 
> In my lousy Indiana Jones impression - "ACA, why does it
> always have to be ACA?" ....
> 
> This whole notion that ACA is a fundamental coordination
> mechanism for shared SCSI access to a target is not headed
> in a good direction - see the recent message from Ralph Weber
> expressing T10's concern that expansion of the usage of ACA is
> an invitation to undesirable denial of service possibilities.
> I will note that the reservation example that Ralph used in his
> message is the sort of thing that can break clustering software,
> although I don't know for certain whether there's any existing
> clustering software that it does in fact break.
> 
> I think Rob and Jim are correct when they describe the current
> 2.4.3 text as being at odds with SAM-2.  So, I think:
> 
> - The text in 2.4.3 that is at odds with SAM-2 should come out.
>         The fact that it was caused by a desire to use ACA makes
>         it doubly suspect.
> - The current mandate for ACA in Section 8.2 exceeds the level
>         stated in the iSCSI requirements draft and I don't believe
>         it represents rough consensus of the WG.  Support for
>         ACA should be a "SHOULD", not a "MUST".
> - The entire effort to use ACA or something like it to serialize
>         error conditions for multiple commands in flight has not been
>         explained well to T10, and what has been explained has not
>         received a good reception.
> 
> The last bullet has a couple of consequences.  First, we should
> take out anything else that's crept into iSCSI in support of this
> use of ACA.  Second, those who want to use ACA or something ACA-like
> for this error coordination across multiple commands in flight
> should write up a submission to T10 explaining what the problem
> is and how ACA or something like it solves the problem.
> 
> I think Ralph is conveying a message from T10 that whatever the
> problem iSCSI has, T10 is not inclined to believe that more use
> of ACA is NOT the solution.  It may take a while to work with T10
> to get the right solution designed, but I'd prefer doing nothing
> over force-fitting ACA to a use that T10 doesn't think is appropriate.
> When we figure out what the right thing is, we can put in the right
> text to describe it.
> 
> Comments?
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
> 
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Wednesday, August 01, 2001 8:01 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI: draft 7: iSCSI response and SCSI sense data
> >
> >
> >
> > Elliot,
> >
> > This issue has some history.  After many took the position you are
> > advocating
> > and I had to drop the check condition all list participants that had
> > something to say adopted the current position in order the
> > benefit from the
> > "serializing" effect of ACA whenever a check condition is
> > originated at the
> > target and the delivery subsystem is still operational.
> >
> > Julo
> >
> >
> > "Elliott, Robert" <Robert.Elliott@compaq.com> on 02-08-2001 02:26:57
> >
> > Please respond to "Elliott, Robert" <Robert.Elliott@compaq.com>
> >
> > To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>
> > cc:
> > 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
> >
> >
> >
> >