Re: iSCSI: draft 7: iSCSI response and SCSI sense data

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

Robert,

> This issue has some history.

I agree that the mapping from response codes to check conditions,
while explanatory, is not appropriate in the iSCSI spec.  I think we
HAVE made a muddle of what's been a somewhat clear, acceptable
tradition.

The key technical point is that a SCSI target SHOULD (and we should
make this a MUST by providing no other mechanism) report every error
that it can report within the confines of SCSI status using SCSI
status.

Specifically, for every SCSI Command PDU, the target should return a
valid SCSI status, or nothing at all (e.g. timeout).

In my opinion, FCP did not necessarily get this quite right, but some
target's do the right thing implementations actually do the right
thing anyway.  Specifically, the definition of the response codes
seems to suggest that if you set both data direction bits (R&W), or
perhaps set the data direction in opposition to the command, you
should get an RSP_CODE=FCP_CMND fields invalid.  It's quite irritating
that FCP targets have this choice, and while one alternative (picking
SCSI status, e.g. 0xb/0x4700---parity error is traditional) can be
signalled cleanly to the end client (the class driver), the other may
be more difficult.

Really, the best use for response information in FCP is to return
status on task management operations.  In this case, SCSI doesn't
define particular status values anyway.  Given that iSCSI have separate
the SCSI Response and Task Management Response PDUs, I don't see why
we need Response information in the SCSI Response at all.  I think we
should dump this field completely.

I particularly think that `target failure' and `delivery subsystem
failure' are two status that should never be explicitly communicated
from the target to the initiator.  These are statuses that the
initiator infers as a result of something like a timeout, a link state
change, or whatnot.

Steph