RE: iSCSI Autosense

["Douglas Otis" <dotis@sanlight.net>]

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Ralph Weber
> Sent: Tuesday, August 29, 2000 8:13 PM
> To: IPS Reflector
> Subject: Re: iSCSI Autosense
>
>
> This is going to be fun, trying to respond to all the information
> and misinformation that's been bandied about today.
>
> David Black's note is correct.  The method for bridging a CA-only
> (Contingent Allegiance only) device to an Autosense representation
> of that device is well known and trivial.  In addition to being
> documented in the requirements, the method is documented in the
> first paragraph of 5.3 in draft-satran-iscsi-01.txt.
>
> I have two minor complaints about the 5.3 wording.
>
> 1) The method will work all the time, so the suggestion
> that it 'may' work is incorrect.
> 2) I would prefer that the REQUEST SENSE command be explicitly
> mentioned not alluded to.
>
> As regards CA, let me restate my position more emphatically.
> CA is a historical artifact that dates to the single byte of
> status model employed by the parallel SCSI bus.
>
> To the best of my knowledge it is extremely difficult to
> implement the CA model in a packetized transfer model because
> the CA condition is cleared by the next command to arrive
> at the target regardless of what kind of command that is.

Not true.  Only for the nexus is this true.

> Since most packetized protocols allow several commands to be
> in flight concurrently between initiator and target, the most
> probably case in a packetized protocol is that an in flight
> command will clear a CA condition long before the initiator
> finds out about it and has a chance to fire off the needed
> REQUEST SENSE in to get the sense data.

These in flight commands are a different nexus such that Sense data is not
lost.  If the device can not maintain separate Sense information BUSY is
returned.

> The bottom line here is that Autosense works for packetized
> protocols and CA does not.  Since it is trivial to translate
> a packetized Autosense front end to the CA behavior of an
> older backend SCSI device, the right thing for iSCSI to do
> is to make Autosense mandatory and not to provide any way
> whatsoever to disable it.

iSCSI does provide a means to disable it, but not to refuse it.

> The fact that SAM is written with a preference for CA is
> (like CA itself) a historical artifact.  So long as the
> wording continues to be correct, it is unlikely that T10
> will change the wording (if it ain't broke don't fix it).
>
> However, the ancient leanings of SAM should not under any
> circumstances be used as a justification for iSCSI support
> for a CA-like interface.  As noted above, CA doesn't work
> for packetized protocols like iSCSI.

A mistaken conclusion.

> ACA (Auto Contingent Allegiance) is absolutely positively
> NOT the super-duper, all fixed up for a packetized world
> brother of CA.  ACA is orthogonal to Autosense and actually
> has no place in this discussion.

Odd, but error control and reporting does not seem orthogonal.

> IN ALL CASES, ACA is optional.  Simply return 0 in the
> NormACA bit (bit 5 byte 3) of the Standard INQUIRY Data
> and you don't support ACA and you are expected to refuse
> to process any CDB with the NACA bit set to 1.

For a means of get things to stop, some mechanism should exist.  This
becomes difficult by suggesting refusal of Autosense is a bad choice.  ACA
may not exist for this purpose if you allow older devices.  I suggest that
there be a means to refuse Autosense.  If the driver can not support this
option, it can refuse the device.

Doug

> ACA is more akin to the SCSI-2 ECA (Extended Contingent
> Allegiance) than it is to either CA or Autosense.  The
> assumption in ACA and ECA is that the initiator needs to
> send several commands to the target in order to cleanup
> whatever error occurred.  The most frequently cited
> excuse for this is the cleanup needed when a tape writes
> past the EOT (End Of Tape) reflective strip.
>
> Thanks.
>
> Ralph Weber
> ENDL Texas
>
>
>