RE: iSCSI Autosense

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

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