SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI : EnableACA



    
    
    Santosh,
    
    The task management functions for iSCSI contain a description the behaviour
    I am talking about.
    This was also subject to a long discussion on the list that included the
    need for ACA behaviour for things like
    task-set full, busy etc. - not considered for ACA. For the later T10 is
    handling making ACA behaviour
    available.
    
    Julo
    
    Santosh Rao <santoshr@cup.hp.com> on 26/04/2001 20:27:34
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   Black_David@emc.com, ips@ece.cmu.edu
    Subject:  Re: iSCSI : EnableACA
    
    
    
    
    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
    > >
    > >
     - santoshr.vcf
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:51 2001
6315 messages in chronological order