Re: iSCSI : EnableACA

[Santosh Rao <santoshr@cup.hp.com>]

Black_David@emc.com wrote:
> 
> > What you are suggesting is that in all cases in which iSCSI would require
> > the target to enter ACA (after a LU reset or a target reset) look forward
> > in the queue and enter ACA only if it finds a CDB marked NACA? (and that
> > includes commands in flight).

Julian,

I am not suggesting any such thing. ACA is only established when the
logical unit completes a command [that had the NACA bit set in its
control byte in the CDB] with a CHECK CONDITION status.

ACA is not established after a LU Reset or Target Reset. On the
contrary, a target reset or LU Reset would clear any existing CAC or
ACA.

- Santosh


> 
> Ok, so why is iSCSI requiring ACA in addition to Unit
> Attention for Clear Task Set, LU Reset and Target Reset?
> In all cases, we're dealing with Initiators whose tasks
> are cleared as a consequence of another Initiator
> issuing the appropriate task management command.
> SAM2 only requires Unit Attention.
> 
> --David
> 
> > -----Original Message-----
> > From: julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com]
> > Sent: Thursday, April 26, 2001 2:22 AM
> > To:   ips@ece.cmu.edu
> > Subject:      Re: iSCSI : EnableACA
> >
> >
> >
> > Santosh,
> >
> > How about a third confusing response?
> >
> > We have introduced the EnableACA (per LU) to enable an initiator unwilling
> > to use it to disable it at the target for this specific Initiator.
> >
> > NormACA - the enquiry bit - indicates support for ACA by the target device
> > server but is a "read-only" bit.
> >
> > What you are suggesting is that in all cases in which iSCSI would require
> > the target to enter ACA (after a LU reset or a target reset) look forward
> > in the queue and enter ACA only if it finds a CDB marked NACA? (and that
> > includes commands in flight).
> >
> > Or to enter ACA only when it finds such a command (sort of "soft ACA")?
> >
> > Both of them sound wrong and complex.
> >
> > Julo
> >
> > Santosh Rao <santoshr@cup.hp.com> on 20/04/2001 22:11:12
> >
> > Please respond to Santosh Rao <santoshr@cup.hp.com>
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI : EnableACA
> >
> >
> >
> >
> > Julian,
> >
> > Would the following not satisfy the requirements for dealing with this
> > ACA issue :
> >
> > 1) Initiators determine the target support for ACA through the NACA bit
> > in the INQUIRY response. (Assuming iSCSI targets have implemented ACA in
> > good faith, this would be supported.)
> >
> > 2) Initiators set the NACA bit in the CDBs of commands that need strong
> > ordering. (This could be a small subset of the I/O traffic to one or
> > more LUNs within the session and not required for all the I/Os in that
> > session.)
> >
> > 3) Any exception condition on a SCSI I/O, for which the NACA bit was set
> > results in ACA being established.
> > Thus, ACA would only be applied if some I/O traffic that required strong
> > ordering was affected by the exception condition.
> >
> > 4) Since the initiator is ACA capable based on its usage of the NACA
> > bit, it should also be capable of performing the desired Clear ACA to
> > recover from this condition.
> >
> > Such an approach would only apply ACA and its corresponding recovery
> > when some strongly ordered I/O encountered an exception condition,
> > rather than applying ACA on a session granularity.
> >
> > To summarize, the above approach allows :
> > - ACA to be turned on/off for a subset of I/Os headed to a LUN
> > - ACA based recovery only used where needed.
> > - Keeps iSCSI ACA un-aware and rightly so, since this is a property of
> > the SCSI ULP.
> > - Avoids applying ACA recovery on a session granularity.
> >
> > What am I missing here (?). Why is an EnableACA needed ?
> >
> > - Santosh
> >
> >
> > julian_satran@il.ibm.com wrote:
> >
> > > All references to
> > > EnableACA are redundant and should be removed for the following reasons
> > > :
> > >
> > > a) An initiator knows whether a target supports ACA from the NACA bit in
> > > the INQUIRY response. When a target indicates support for ACA, the
> > > initiator can use it by setting the NACA bit in the CDBs it sends. There
> > > is NO need for any sort of negotiation of this behaviour above and
> > > beyond what is already provided thru SCSI mechanisms.
> > >
> > > b) The ACA is a SCSI ULP concept and iSCSI should not be negotiating its
> > > use or lack thereof. This is done thru the NACA bit in CDBs.
> > >
> > > c) (As a side note, the description of EnableACA on pg 127 refers to its
> > > presence in the lun control mode page, but it is actually present in the
> > > protocol specific port page.)
> > >
> > > d) ACA is a LUN-level (more an I/O level) control option. It MUST NOT be
> > > negotiated on a per-session basis. SCSI allows initiators to request ACA
> > > behaviour on a per I/O basis through the use of NACA bit in the CDBs.
> > >
> >
> >  +++ We have required ACA to be supported by all new iSCSI targets and
> >  several
> >  actions require the target to enter ACA state.
> >  It was brought to our attention that many initiators will not react
> >  properly to a
> >  target entering ACA state (not do the reset).
> >  The EnableACA bit and key are meant to enable an initiator to control
> > this
> >  iSCSI specific ACA behaviour.  This behaviour is related to
> > asynchronous
> >  events and is not controlled by the NACA CDB bit.
> >
> >  ++++
> >  - santoshr.vcf
> >
> >
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard