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

["Eddy Quicksall" <ESQuicksall@hotmail.com>]

Actually, I love layering myself...but this does not really seem to be a
layering issue because it is the iSCSI layer that is having the problem (and
from a ULP point of view, that is part of the target). Why should it not be
able to produce the check condition if the SCSI layer never gets involved.
Not to allow it to produce a check condition would be the same as saying
||SCSI is not allowed to say the same thing (e.g. 44h 00h  INTERNAL TARGET
FAILURE).

--Target Failure - there is a failure of the "target" and that includes the
iSCSI layer.
--Delivery Subsystem Failure - e.g., the "target" can't get to the next
layer
--Unsolicited Data Rejected - this should probably not cause a check
condition because the initiator SCSI layer did not do it ... the initiator
iSCSI layer did it and he should just check the iSCSI response.
--Not enough unsolicited - dito
--SNACK Rejected - dito

For the items that are strictly iSCSI, they should only report iSCSI
response codes and let the initiator iSCSI take care of reporting to the ULP
as it sees fit (or try to recover).

Eddy
----- Original Message -----
From: <Black_David@emc.com>
To: <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Thursday, August 02, 2001 10:21 AM
Subject: RE: iSCSI: draft 7: iSCSI response and SCSI sense data


> > Could you please quote us which part of SAM-2 this is
> > violating.
>
> As Rob Elliott said:
>
> > 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.
>
> So, just generate the CHECK CONDITION and don't try to use the
> iSCSI Service Response to further qualify it, as Mallikarjun
> suggests:
>
> > 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.
>
> Thanks,
> --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
> ---------------------------------------------------
>