|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI version 20 draftDavid, 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 |