Re: iSCSI ERT: handling for iSCSI response codes

[Stephen Bailey <steph@cs.uchicago.edu>]

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