Re: iSCSI : Initiators expected to fake CHECK CONDITIONS.

[julian_satran@il.ibm.com]

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 <santoshr@cup.hp.com> on 10/01/2001 05:05:43

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

To:   IPS Reflector <ips@ece.cmu.edu>
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