Subject: Re: iSCSI ERT: handling for iSCSI response codes

From: [email-masked]
Date: Sun, 17 Jun 2001 15:18:38 +0300

Steph,

That is an interesting change in opinion. When I suggested the same thing
some releases ago for the same set of reasons
(I even suggested avoiding the response codes at all!) as there is no
noticeable difference in handling the heat of your response was felt at
6000 miles.

However I am not sure anymore that given the need for a clearing action for
most of those cases that we should not keep
the treatment within the iSCSI layer and create an
iSCSI-exception-condition (for all iSCSI created responses) cleared through
an iSCSI task management function (clear-iSCSI-exception) and reject all
intervening commands.

This type of handling will let us build independent of SCSI and keep the
layering purists happy.

Regards,
Julo

Stephen Bailey <[email-masked]> on 14-06-2001 05:42:09

Please respond to Stephen Bailey <[email-masked]>

To:   [email-masked]
cc:   Julian Satran/Haifa/IBM@IBMIL, [email-masked],
      [email-masked], [email-masked],
      [email-masked], John Hufferd/San Jose/IBM@IBMUS,
      [email-masked]
Subject:  Re: iSCSI ERT: handling for iSCSI response codes

Mallikarjun,

> Comments?

Hmm.  Ok, I agree.

For example, I never really thought:

>       0x02 - Delivery Subsystem Failure

was the right way to report in-band integrity errors.  Delivery
subsystem failure usually means something that is not even detectable
by the target, like a timeout.  As such, I agree that the target
shouldn't be responding this back.

Yes, I have seen many FCP targets do exactly what you're suggesting
here.  In fact 0xB 0x4700 (good ole SCSI parity error) is code for
many different protocol errors which are detectable and attributable
to a particular SCSI command.  For example, bogus settings of FCP
F_CTL bits.

So, assuming that Target Failure, Delivery Subsystem Failure are all
attributable to a SCSI command, I agree they should create CHECK
conditions.

The place where response values are justified is if the error is
attributable to something other than a SCSI command, such as a task
management function.  For example, task management function rejected
(which we don't seem to have).  If we were anticipating any of these
as a response to task management, they should remain, or perhaps we
should define new, more specifically task management related responses
codes.

I'm not clear on what you're proposing for SNACK rejected, but, since
it's not CHECK CONDITION, I'm sure whatever you have in mind is fine,
but we need to document it better :^)

Steph

---

From: Stephen Bailey <[email-masked]>
Date: Sun, 17 Jun 2001 11:27:35 -0400

Julian,

> That is an interesting change in opinion.

If it is, I am sorry.  I was mistaken.

However, I thought there was a difference between what I was arguing
against then and what we are discussing here.  Whatever the case, it's
irrelevant.  Here's what I think now, and I apologize for either my
misunderstanding, failure to communicate effectively, or my sheer
idiocy, if this contradicts any previous statements.

What I am opposed to is the initiator synthesizing SCSI status.  On a
irrecoverable initiator-detected failure during an identified task,
the initiator should report an appropriate service response code, and
not a CHECK CONDITION.

However, on the target side, the target should report every error for
which it is possible to do so, with an appropriate SCSI status code
(e.g. CHECK CONDITION).  Response codes (or an analogous mechanism)
are STILL the right thing for errors which can not be reported with
SCSI status, such as task management errors.  When I say analogous
mechanism, either the iSCSI Reject or Task Management response (or
both) could convey the equivalent information.

I could well imagine arguing that target responses should be signalled
analogously (equivalently) to FCP (SRP etc.), which means a single
response PDU covers all cases (command response and task management
response).  The role of the response code is clear in that case.  Once
upon a time I held out hope for that, but clearly we're far from there
now, so I won't continue to argue for it.

Presently, I agree that the response field in the SCSI Response PDU
seems superfluous.

It's only 5435 miles from Lawrence to Haifa.  We're not as far apart
on this as you suggest :^)

Steph