SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI version 20 draft



    David,
    
    Let me note that both ACA and UA interlock are valid command ordering
    mechanisms and both are SAM-2 concepts.
    
    > I disagree, Section 5.9.1.2 of SAM-2 (sam2r24) says:
    > 
    >   When a device server terminates a command with a CHECK CONDITION status,
    >   either an CA or ACA condition is established within the task set.
    > 
    > That's sufficient language to cause establishment of ACA.
    
    Completely agreed wrt ACA.  But let's be careful wrt UA interlock, for a CA 
    *does not* trigger a UA interlock.  A UA interlock is triggered on a UA, and a
    UA can only be mandated in the iSCSI spec for the case of "a connection loss 
    with the I_T nexus intact".  That's all Rob's second para is attempting to cover
    along with the rationale (The orginal rev19 text mandated UA for the same reason).
    
    > This creation of a new unit attention to deal with this situation
    > (e.g., so that an initiator can control command ordering in these
    > implicit termination cases without resorting to ACA) is a functional
    > addition to iSCSI, complete with assignment of a new unit attention
    > code; it does not appear to fix anything that is broken. 
    
    IMHO, a UA is *not* a "functional addition" to iSCSI, a UA has been 
    in the iSCSI spec for several months!
    
    There are a couple of options I can think of to deal with this -
    
    A. Rob's UA text with the original (rev19) ASC/ASCQ values.
    B. Rob's UA text with no ASC/ASCQ values.
    C. Rob's UA text with his proposed ASC/ASCQ values.
    
    Perhaps your comment is specifically about Option.C.  I can agree with
    you on that procedural aspect.  Out of A and B, I have a mild preference
    for A (because I believe there's some value in consistency across all targets,
    for an initiator), but I'd be okay with Option.B.
    
    Hope that clarifies the technical issue.
    
    Thanks.
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions
    Hewlett-Packard MS 5668 
    Roseville CA 95747
    cbm@rose.hp.com
    
    ----- Original Message ----- 
    From: <Black_David@emc.com>
    To: <cbm@rose.hp.com>; <ips@ece.cmu.edu>
    Sent: Thursday, January 23, 2003 5:45 PM
    Subject: RE: iSCSI version 20 draft
    
    
    > Mallikarjun,
    > 
    > > > For this to go into the final RFC, I need a crisp explanation
    > > > of what's broken in the -20 text.
    > > 
    > > That's fair.  There are two reasons.
    > > 
    > > - Cases a, b and c in the rev20 text below are *not* covered by SCSI
    > >    standards in the case of single connection failures in a
    > multi-connection
    > >    session by definition, because the I_T nexus is still intact.
    > Implementers
    > >    cannot take guidance from SAM-2 or SPC3 as the text suggests.
    > > However additional actions may have to be taken at SCSI level 
    > > depending on the SCSI context as defined by the
    > > SCSI standards (e.g., queued commands and ACA, UA for the 
    > > next command on the I_T nexus in cases a), b), and
    > > c) etc. - see [SAM] and [SPC3]).
    > 
    > I disagree, Section 5.9.1.2 of SAM-2 (sam2r24) says:
    > 
    >   When a device server terminates a command with a CHECK CONDITION status,
    >   either an CA or ACA condition is established within the task set.
    > 
    > That's sufficient language to cause establishment of ACA (if NACA is
    > set) in all four cases as it has no dependency on continued
    > existence of the I_T nexus.  So, although Rob's first paragraph may be
    > more carefully edited than the existing text, it does not appear to
    > fix anything that is actually broken.
    > 
    > > -  Command ordering even in the face of errors for an I_T nexus is
    > >     what iSCSI signed up to do quite a while ago (Nashua F2F?).  The
    > >     careful line we've been treading is that iSCSI doesn't require
    > >     initiators to use command ordering, but iSCSI specifies the
    > >     guaranteed target semantics _in case_ the initiator wants to
    > >     employ it.  A single connection drop in a multi-connection
    > >     session is clearly an iSCSI scenario that could violate the
    > >     command ordering, and the target ordering semantics in this
    > >     case will have to be clearly called out in the iSCSI RFC
    > >     as elsewhere.
    > 
    > I don't see any additional rationale here beyond the original
    > statement that SAM-2 does not apply ACA to events that don't destroy
    > the I_T Nexus - see above.
    > 
    > Going on to Rob's second paragraph, I have to throw a "process" flag
    > on the play.  Rob describes his paragraph as:
    > 
    > > The second paragraph explains the unit attention that must appear
    > > on the next command on the wire (and lists the additional sense
    > > code to use). This is not an additional sense code for an internal-only
    > > command status, so is appropriate for iSCSI to mention.
    > > We'll assign that code in SPC-3.
    > 
    > This creation of a new unit attention to deal with this situation
    > (e.g., so that an initiator can control command ordering in these
    > implicit termination cases without resorting to ACA) is a functional
    > addition to iSCSI, complete with assignment of a new unit attention
    > code; it does not appear to fix anything that is broken.  While I'm
    > inclined to believe that this is a useful "nice to have" addition,
    > I believe adding it at this late stage is out of bounds, and I'm
    > concerned that working through the detailed implications will take
    > us into SAM-3's I_T nexus loss handling, where I believe we do not
    > want to go.
    > 
    > So, I do not see the need for any text changes to -20.
    > 
    > In order not to lose the careful thinking that has gone into this
    > issue, could I suggest that you and Rob write up an Internet-Draft on
    > this topic?  A good discussion of what ACA does and how to use it
    > would doubtless be useful to implementers who do not have the benefit
    > of T10's experience in this area.  That draft could also propose
    > the new unit attention condition and code, but would probably need
    > to make it OPTIONAL.
    > 
    > Sorry/Thanks,
    > --David
    > ----------------------------------------------------
    > David L. Black, Senior Technologist
    > EMC Corporation, 176 South St., Hopkinton, MA  01748
    > +1 (508) 293-7953             FAX: +1 (508) 293-7786
    > black_david@emc.com        Mobile: +1 (978) 394-7754
    > ----------------------------------------------------
    > 
    > 
    
    


Home

Last updated: Fri Jan 24 22:19:28 2003
12258 messages in chronological order