RE: RE: iSCSI Autosense

[somesh_gupta@hp.com]

I really don't know where keeping the A bit helps anyone. All that
is saying is that the sense data is returned with the command
status. 

First of all, we should have an enumeration of modern (is it
reasonable to go back only 3 yrs?) devices that do not support
autosense. This would give this some realistic foundation. If we
cannot list a reasonable number (?) of devices that don't support
autosense, then I think it is a meaningless discussion. In the future,
it seems unlikely that devices will not support autosense.

Then there is the other aspect

1. A device that does not support autosense is connected through
a bridge. In this case, as mentioned before, the bridge can hide the
lack of autosense support by the device.

2. There is no bridge and the device supports a native iSCSI interface.
In this case the it is probably a new rev of the device and probably a
small incremental effort to support autosense. If any case, the
software/firmware driver (of course there has to be
one managing the iSCSI chip/adpater whatever) can provide the necessary
functionality.

It seems that if the lack of autosense support has been very uncommon,
and is rapidly dying, it is better to shift the burden of "providing
autosense" to the oddball cases rather than spread the malaise.

Anyhow, without a list of devices that do not support autosense,
my practical engineer side is not going to be convinced that it
makes any sense to keep the A bit.

Somesh

> -----Original Message-----
> From: dotis@sanlight.net [mailto:dotis@sanlight.net]
> Sent: Wednesday, August 30, 2000 3:31 PM
> To: ENDL_TX@computer.org
> Cc: dotis@sanlight.net; ips@ece.cmu.edu
> Subject: FW: RE: iSCSI Autosense
> 
> 
> 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
> 
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu 
> [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Ralph Weber
> > Sent: Wednesday, August 30, 2000 11:45 AM
> > Cc: ips@ece.cmu.edu
> > Subject: Re: iSCSI Autosense
> >
> >
> > Julo,
> >
> > } How are volume change events supposed to be treated with CA,
> > } ACA and autosense...<snip>
> >
> > There are two ways to report a Unit Attention condition:
> >
> >   1) Asynchronous Event Reporting
> >   2) Use of a Unit Attention CHECK CONDITION
> >
> > Asynchronous Event Reporting is optional for both targets and
> > initiators, and must be enabled by the initiator via the Control
> > mode page before it can be used.  I have assumed that 3.6 in
> > draft-satran-iscsi-01.txt is somehow related to AER, and have
> > yet to work through the details.
> >
> > The use of a Unit Attention CHECK CONDITION follows all the
> > same rules as any other CHECK CONDITION with respect to CA,
> > Autosense, and ACA.  When this mechanism is used (which is
> > far and away the most common case), there are no functional
> > differences between a Unit Attention CHECK CONDITION and a
> > Hardware Error CHECK CONDITION.
> >
> > I'll provide detailed answers to detailed questions, but the
> > above information seems like about all that can be said in
> > response to the question raised.
> >
> > }<snip> (or for that matter any Async. Event that intends
> > } to convey to an initiator state information that the initiator
> > } should be aware of before sending commands - i.e. how is state
> > } sync. achieved)?
> >
> > I believe that the vast majority of asynchronous events do
> > not require the initiator to be aware of them before other
> > commands are sent.  That is, I believe that 'volume change'
> > is the exception not the rule and somebody is going to have
> > to produce a substantial list of exceptions before I'm likely
> > to change my opinion.
> >
> > If indeed 'volume change' is the exception, then I have no
> > problems with according it exceptional handling, as in
> > forcing logouts (or whatever is equivalent) for all initiators
> > as a response.
> >
> > } I was under the impression that this is one of vestigial uses
> > } of CA.
> >
> > I believe that the impression is incorrect and I have explained
> > at great length why CA offers not even a fig leaf's worth of
> > protection.  I regret that I cannot argue against this incorrect
> > impression any more forcefully than I already have.
> >
> > } It is obvious that autosense is fine but until I can't(sic) be
> > } convinced that it is completely orthogonal to CA use (or to some
> > } other mechanism that can assure state sync) I would be reluctant
> > } to force it.
> >
> > CA is NOT orthogonal to Autosense.  They are two mechanisms for
> > achieving the same end, which is to ensure that the sense data
> > for a CHECK CONDITION reaches the initiator.  However, CA is
> > based on assumptions that apply ONLY to the interlocked parallel
> > SCSI bus.  Therefore, the only mechanism that is available to
> > a packetized protocol is Autosense.
> >
> > Combining CA with a packetized protocol does not improve reliability
> > or state synchronization between initiator and target.  Exactly the
> > opposite is true, CA depends for is proper operation on a level of
> > state synchronization between initiator and target that is available
> > ONLY on the interlocked parallel SCSI bus.  Combining CA with a
> > packetized protocol presents a fictitious image of synchronization,
> > that's all it does.
> >
> > } If state sync. is provided by some other means that I 
> will be happy
> > } to oblige and assume autosense is always there.
> >
> > ACA provides state synchronization between initiators and targets
> > and I have not contested support for ACA in iSCSI.  In fact, as
> > you can see from my response this morning to Douglas Otis, I have
> > reviewed the ACA support provisions in the iSCSI draft and verified
> > that they are appropriate.
> >
> > I submit that ACA is the 'other means' that you have requested.
> >
> > Thanks.
> >
> > Ralph Weber
> > ENDL Texas
> >
> >
> >
>