Re: iSCSI Autosense

[Ralph Weber <ralphoweber@compuserve.com>]

Douglas,

Since your response contains nothing that disputes the changes
proposed for draft-satran-iscsi-01.txt, I assume that you agree
with the changes.

You are to be commended for your consistency.  Your Visegrip(TM)
on the option remains without a hint of diminution.

Thanks.

Ralph Weber
ENDL Texas

Douglas Otis wrote:

>
> 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
> >