SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

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


Home

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