RE: iSCSI Autosense

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

Ralph,

Few wish to mess with odd devices that are talking SCSI in some unknown
fashion.  To add ACA emulation at an adapter and then fiddle code in the
original application to send now expected ACA commands seems counter
productive with these low reward tasks should there be a prior reliance on
CA.  SAM simply suggests that Sense is not returned as an indication of no
Autosense.  An explicit refusal could signal the presents of some legacy
hardware best left untouched and forgotten.  It should mean less work by
leaving it to the application.  This is not a matter of determining which
devices support Autosense but rather which devices support ACA or may rely
on CA. The adapter should be able to work out if refusal is desired.
Perhaps a response to login could provide this feedback.  An alternative is
to not send Sense without notification and leave everything as is with this
understanding.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Ralph Weber
> Sent: Wednesday, August 30, 2000 4:18 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI Autosense
>
>
> Douglas,
>
> So, let's see if I understand what you are proposing:
>
>   1) Keep the A bit
>   2) Restrict usage of A=1 to those cases where the only
>      Task Attribute value supported is 0 (Untagged)
>   3) In all other cases the receipt of a SCSI Command packet
>      with A=1 would be cause for a protocol error
>
> That being the case, there are a couple of editorial fixes
> needed at the end of 3.2.1 in draft-satran-iscsi-01.txt as well:
>
>   a) Remove the reference to SAM-2 in the description of the
>      A bit.  There is nothing in SAM-2 that will be even
>      remotely helpful to the reader.
>   b) Change the last sentence of the clause as follows to
>      clarify the obligations of the initiator:
>
>      "If autosense is turned off, the initiator must explicitly request
>      transfer of the sense data by sending a REQUEST SENSE command as
>      the first command delivered to the target after a command has
>      completed with a CHECK CONDITION status."
>
> Good grief.  For a group that prides itself on limiting the
> options in their
> standards, you all sure do cling to them with Visegrip(TM) tenacity.
>
> Thanks.
>
> Ralph Weber
> ENDL Texas
>
> Douglas Otis wrote:
>
> >
> > Ralph,
> >
> > Perhaps I should say Mr. SCSI as I would not wish to slander obvious
> > knowledge even if I may disagree. I agree ACA provides desired
> interlocks
> > and Autosense is also highly desired. I was not concerned about
> disk drives
> > as these products are easily found supporting these standards
> and represent
> > no change to existing software.  Although your emulation description
> > approximates ACA with CA devices, it is not as simple as not
> doing it at all
> > in cases where it is not needed.  For the odd device that does run one
> > command per nexus and where such use is not a horrific
> bottleneck and the
> > removal of Autosense leaves the operation of the device
> unchanged, why not
> > refuse Autosense?  Loaders, tape and every other odd widget you
> can imagine
> > may fall into that CA category.  Mucking with ACA emulation
> seems wrong in
> > these cases where this fig leaf is enough.  By creating an Autosense
> > refusal, at least those such as yourself wishing to have a pure
> environment
> > can enforce such desires.
> >
> > Doug
>