Subject: Re: iSCSI : Initiators expected to fake CHECK CONDITIONS.

From: [email-masked]
Date: Fri, 12 Jan 2001 09:41:36 +0200

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).

And an error in the iSCSI layer gets reported by the next layer - that is
the regular layering technique (and BTW I am getting a bit uneasy about all
this preaching on layering when it is not obvious that you understand all
the implications of the point).

Julo

Santosh Rao <[email-masked]> on 10/01/2001 05:05:43

Please respond to Santosh Rao <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:
Subject:  iSCSI : Initiators expected to fake CHECK CONDITIONS.

Julian,

My comments embedded below.

Thanks,
Santosh

> Section 4.4. Format Errors
> ====================
> Quoting from the draft :

> "When a session is active whenever an initiator receives an iSCSI PDU
>  with a format error, for which it has an outstanding task, it MUST
>  abort the target task and report the error as a SCSI check condition
>  status with a sense key of 4h (hardware error)."

> What is the reasoning behind this ? It seems to complicate Format
Error
> Handling with no clear benefit. Is it the expectation that iSCSI
> initiators
> will fake a format error as a CHECK CONDITION back to the SCSI
>Layer ? If so, why ? And why the choice of "Hardware Error" ?

[js} the error was generated by a faulty controller and I did not find
any
other SCSI sense fit for it[/js]

A clean layering should be maintained between iSCSI layer errors and
SCSI layer errors. A format error on a iSCSI PDU header does not
constitute a SCSI error. The specific error returned back to the
SCSI upper layer driver in this case is really O.S. specific since each
O.S. has its own error codes to deal with interconnect transport errors.

Expecting initiators to fabricate sense data on behalf of a target and
faking a CHECK CONDITION back to the upper layers is :
a) violating layering b/n iSCSI and SCSI layers.
b) adds un-necessary complexity to the initiator which now needs to
build sense data internally on behalf of a target.
c) will cause different error recovery paths to be taken in the upper
layer SCSI driver which is expecting to see some std O.S. defined error
codes to be returned on interconnect transport errors.

> Last, but not the least, the above statement is referring to all iSCSI

> PDUs and advocates that iSCSI initiators must fake a CHECK CONDITION
> back to the SCSI layer on any format error of any iSCSI PDU.

[js] only if a task is running [/js]

I'm somewhat confused here. Let us say a format error occurs on a
Logout. What is the error recovery to be done in this case if there are
other outstanding tasks ? Is this section advocating erroring ALL the
outstanding tasks [that did not encounter format error] ?

> This is not applicable for non-scsi iSCSI PDUs which have no SCSI
> context. I believe the REJECT PDU should only be used for non-scsi
> PDUs since Rejects to SCSI PDUs will need a different type of reason
> code/explanation information best fitted into the existing SCSI
Response

 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Fri, 12 Jan 2001 20:14:20 -0800

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:  [email-masked]
> To:      [email-masked]

---

From: Stephen Bailey <[email-masked]>
Date: Sun, 14 Jan 2001 09:10:56 -0600

Julian,

This seems like the zillionth time aired this same disagreement.

I think we should try to reach a WG consensus on whether iSCSI should
use SCSI status as a means for reporting protocol-related errors, and
kill it once and for all.

I'm strongly against it.

> the implications of the point).

Santosh seems to understand 100%.  I agree with Santosh.

SAM defines three pieces of status returned by Execute Command()
(which is, in turn implemented by each SCSI protocol, e.g. iSCSI):
  1) Service Response: task complete, linked command complete, service
     delivery or target failure.
  2) SCSI status byte
  3) SCSI sense data

SAM clearly suggest that a protocol's means for signalling
protocol-detected errors is the service response status when it says:

  The actual protocol events corresponding to a response of TASK
  COMPLETE, LINKED COMMAND COMPLETE or SERVICE DELIVERY OR TARGET
  FAILURE shall be specified in each protocol standard.

Note that defining protocol error events in terms of TC, LCC, SDF and
TF, remains an abstraction.  An actual implementation can chose to
signal these events by whatever means.  All SCSI implementations I've
seen do have a status return component which exactly corresponds to
SAM's service response status, but has more than just these four
alternatives.  Typically, that includes things like success, command
timeout, addressing failure (selection timeout in ||SCSI, bad AL_PA in
FCAL, etc.), command aborted, bus parity error, etc..  What iSCSI does
need to do is clearly define its error events AS protocol events,
which is what describing them in terms of the SAM specified set does.

||SCSI, FCP and the other SCSI protocol standards do this.

Operationally, this means that in iSCSI:

  o protocol-specific errors for a task detected by the target without
    a CLEARLY corresponding SCSI error return should be signalled
    using the iSCSI response mechanism.

    The initiator will handle these errors by recording them in some
    appropriate way, and selecting an appropriate service response
    status value.

  o errors for a task detected directly by the initiator are handled
    by recording them in some appropriate way, and selecting an
    appropriate service response status value.

I don't know that there's a single sentence or section in SAM which
says this, but it clearly implies that the components of SCSI status
(status byte and sense) are data which are CARRIED (not created) by
SCSI protocols, for the use of the protocol-independent components.
For example, a disk peripheral driver reacts to SCSI status and sense
generated by disks for SCSI operations that it starts.

SCSI status should be equivalent to the SCSI status returned by the
logical unit.

SCSI protocols are not citizens of the SCSI status space, which means
that the real citizens (the command standards, and SAM), may define
semantics of SCSI error codes which conflict with iSCSI's selections.
The `hardware error' sense key might be defined to mean something very
specific within a particular SCSI peripheral command set, and your
choice of synthesizing SCSI status within the protocol could cause
this behavior to misfire.

> any other SCSI sense fit for it[/js]

That's because there IS no SCSI sense fit for it.  It is a
protocol-detected, protocol-unique error.  Therefore it should be
signalled using the service response status.

Steph