Re: iSCSI : Initiators expected to fake CHECK CONDITIONS.

[julian_satran@il.ibm.com]

Santosh,

I understand your concerns.

The previous versions had the response field in the response PDU as a
summary of several format errors.  The format was selected to be close to
FCP.  FCP cumulates there the task management responses (for which we have
a separate  PDU) and the format errors.

Surfacing the Service Response can be accomplished either through a command
response  or through a  command reject  and we decided that with the format
we have we can give more details than with the response field.

However we could not find any mapping of the a service response neither in
SAM nor in FCP nor in CAM.  We could leave this mapping to be
implementation dependent (and that is a perfectly valid choice as it has to
be supported by the OS) or we could map it into a Status and Sense and we
though that this is closer to what we would like an initiator to do in
order to express its unhappiness with a specific target implementation
(regardless of the sacrosanct layering).

Nevertheless we are open to suggestions.

Regards,
Julo



Santosh Rao <santoshr@cup.hp.com> on 13/01/2001 06:14:20

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI : Initiators expected to fake CHECK CONDITIONS.




Julian,

I had 2 concerns on the format error handling issue :

1) This error recovery is applicable for the SCSI Command PDU. What is the
error recovery for a format error on a Login, Logout, Text, NOP-OUT,
NOP-IN,
SCSI Task Management Command PDU ? These commands are either :
not from the scsi layer and their responses do not get sent up the stack to
the scsi layer.
or
in the case of scsi task mgmt cmds, the response does not contain sense
data.

How are the above to be handled ?

2) On the concept of initiators generating sense data on behalf of targets
and
faking a HARDWARE ERROR, this is not the approach parallel scsi and fibre
channel take. In the case of fibre channel, a header format error results
in
Response Info being generated in FCP_RSP. (for scsi pdu's). However, I
noticed
that the latest version of the iSCSI draft has removed all references to
response length and response data, and hence, it looks like this approach
is
not being considered (?)

Generating sense data in an initiator is adding complexity and makes iSCSI
HBA
drivers SPC-2 aware in terms of the content and generation of sense data.
Also, we will need to check some implementations of the upper scsi layer
drivers to see if this can cause any different form of error recovery to be
taken such as issuing a BDR to recover from HARDWARE ERRORs ?

Regards,
Santosh


> Subject:  Re: iSCSI : Initiators expected to fake CHECK CONDITIONS.
> Date:    Fri, 12 Jan 2001 09:41:36 +0200
> From:  julian_satran@il.ibm.com
> To:      ips@ece.cmu.edu

> Santosh,

> A machine producing a format error is DEFECTIVE and this a reported as
> hardware error by SCSI (as SCSI does not distinguish between hardware and
> firmware and rightfully so).



 - santoshr.vcf