SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Implicit Termination of Tasks



    I agree with the last paragraph here ... I was just about to send an EMAIL
    when I noticed this one. I'll just add my justification here.
    
    The ASC/ASCQ of COMMAND TO LOGICAL UNIT FAILED does not really depict what
    may have happened. Consider the following:
    
    1) all commands up to this point have completed
    2) command n is sent on connection 0 but never arrives at the target
    3) the target notices the lost connection
    4) a UA needs to be set if for no other reason to trigger ACA and if ACA is
    not being used, to inform the application at the initiator that something
    went wrong (as far as he knew, command n is being processed)
    
    Since the target would not know that command n was on its way, it could not
    use logic to determine if it should or should not set the UA ... so it would
    have to set it regardless. And if step 2 did not really exist, setting it to
    COMMAND TO LOGICAL UNIT FAILED would not really be accurate. I'm not sure if
    even I/O PROCESS TERMINATED is appropriate for this case either.
    
    Are we allowed to invent a new ASC/ASCQ - such as CONNECTION LOST?
    
    Eddy 
    
    -----Original Message-----
    From: Mallikarjun C. [mailto:cbm@rose.hp.com]
    Sent: Tuesday, January 07, 2003 11:05 PM
    To: Black_David@emc.com; ips@ece.cmu.edu
    Subject: Re: iSCSI: Implicit Termination of Tasks
    
    
    David,
    
    I disagree with your suggestion.
    
    I believe that cases a, b and c (as written) are necessary and sufficient 
    cases for generating an internal CHECK CONDITION because
    our intent is to deliver on the promise of "ordering in the face of errors
    on one I_T nexus", *not* to gurantee the creation of  cross-initiator ACA
    based on TST and QErr bit settings - simply because there are no iSCSI
    ordering guarantees involved across independent I_T nexuses.  
    
    IOW, iSCSI spec today takes the position that the first three cases 
    are of potential interest to SCSI layer in view of iSCSI's ordering
    guarantee
    while the last case (d) is an iSCSI dynamic that has no bearing on the
    ordering guarantee.  I think that's a very reasonable position.
    
    On a related separate topic, the current ASC/ASCQ value specification 
    for the implicit termination in the iSCSI spec is quite limiting as Eddy
    pointed 
    out - I surprisingly overlooked the "array only" qualifier when I originally
    suggested it.....  I suggest that we change it to the following - 
    
    00/06  DTLPWRSOMCAEBK  I/O PROCESS TERMINATED
    
    Regards.
    --
    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: <david.brown@trebia.com>; <ips@ece.cmu.edu>
    Sent: Tuesday, January 07, 2003 5:57 PM
    Subject: RE: iSCSI: Implicit Termination of Tasks
    
    
    > Folks,
    > 
    > We need to drive this issue to closure.  The gory details of the
    > cross-initiator effects of task termination with CHECK CONDITION
    > are summarized in Table 25 of Section 5.9.1.2 of SAM-2, and the
    > next four subsections describe how this affects new tasks.  As
    > David Brown pointed out, the important behavior to note is that
    > when TST is 0, any such termination affects *all* tasks regardless
    > of initiator, and if it results in an ACA, that affects
    > *all* existing and new tasks until the ACA cleared.  FWIW, iSCSI's
    > requirement that autosense MUST be used eliminates the possibility
    > of a new task being created while CA is in effect as the CA is
    > immediately cleared by autosense.
    > 
    > Given this, especially its ACA aspects, and the fact that iSCSI needs
    > to support ACA, the distinction currently made in Section 6.5 between
    > connection closure and session closure seems wrong - I'm inclined
    > to agree with David Brown and Eddy Quicksall that all four cases
    > in Section 6.5 need to implicitly terminate the tasks with CHECK
    > CONDITION for consistency, and I also think that David Brown's
    > add text observing that there may be cross-initiator side effects
    > depending on how CA and ACA are handled is reasonable, but I would
    > limit it to about what I just wrote plus advice to consult SAM-2.
    > 
    > Anyone want to disagree?
    > 
    > Thanks,
    > --David
    > 
    > 
    > > I don't understand why the generation of CHECK CONDITIONs is immaterial
    > when
    > > a session is closed.  When a check condition generates a CA or ACA, it
    can
    > > affect tasks from other initiators, too.  Look at the TST and QErr bits
    in
    > > the Control mode page.
    > > 
    > > If the TST bit, in the Control mode page, is zero and the QErr data
    field,
    > > in the same mode page, contains 01b, then a check condition causes all
    > tasks
    > > from all initiators to be aborted.
    > > 
    > > If TST is zero and QErr is not 01b, then all tasks from other initiators
    > are
    > > temporarily blocked by a CA or ACA.  The situation in which an ACA was
    > > generated and the session was closed is particularly problematic,
    because
    > > the initiator that caused the ACA is gone.  One of the other initiators
    > > would need to reset the unit, or send a PERSISTENT RESERVE OUT, to clear
    > the
    > > ACA.
    > > 
    > > It wouldn't have done any harm to make the last paragraph of 6.5 apply
    to
    > > clause (d), namely session closure.  It certainly would have been helped
    > if
    > > the paragraph referred to CA and ACA explicitly.  Such a statement would
    > > have made clear the underlying assumption, namely that a check condition
    > > never affects other initiators, as long as the target 
    > > implements autosense.
    > > 
    > > Bottom line: If I understand the SAM and SPC specs correctly, the
    current
    > > draft of the iSCSI spec is incorrect.  Clause (d) of 6.5 should cause
    the
    > > tasks to be terminated with a check condition, just like clauses (a),
    (b),
    > > and (c).  The check condition is visible externally in two situations:
    > > 
    > > 1.  Closing a session will cause tasks from other sessions to be
    aborted,
    > if
    > > QErr contains 01b and TST contains 0.
    > > 2.  Closing a session will cause tasks from other sessions to be
    blocked,
    > if
    > > QErr contains 00b (or 011b) and TST contains 0 and any of the terminated
    > > commands had the NACA bit set.
    > > 
    > > dj
    > > 
    > > 
    > > -----Original Message-----
    > > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
    > > Sent: Tuesday, January 07, 2003 8:52 AM
    > > To: 'Mallikarjun C.'; ips@ece.cmu.edu
    > > Subject: RE: iSCSI: Implicit Termination of Tasks
    > > 
    > > 
    > > If it never makes it back to the initiator, then it is an 
    > > implementation
    > > issue. As long as the target maintains all ordering 
    > > requirements (iSCSI out
    > > of order commands and SCSI queued commands), all should be 
    > > well and there
    > > would be no requirement imposed in the spec to implement this.
    > > 
    > > If would be better to have just given the paragraph below as an
    > > implementation note. As long as we all understand what your 
    > > intent was, then
    > > we should be OK (and you have now explained that).
    > > 
    > > Thanks
    > > 
    > > Eddy
    > > 
    > > -----Original Message-----
    > > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
    > > Sent: Monday, January 06, 2003 9:15 PM
    > > To: Eddy_Quicksall@iVivity.com; ips@ece.cmu.edu
    > > Subject: Re: iSCSI: Implicit Termination of Tasks
    > > 
    > > 
    > > Eddy,
    > > 
    > > iSCSI's design goal was to ensure command ordering
    > > even in the face of errors - ultimately, we wanted the SCSI
    > > execution ordering to be correct while running on iSCSI.
    > > This should be able to be guaranteed by the iSCSI targets,
    > > while initiators may/may not employ command ordering.
    > > 
    > > For this to happen, iSCSI must both maintain its delivery
    > > ordering, and require SCSI CHECK CONDITIONs to
    > > be locally triggered on the target on iSCSI exception
    > > conditions such as connection terminations.  The CHECK
    > > CONDITION would then cause the ACA/persistent-UA to
    > > be invoked if so desired by the initiator.
    > > 
    > > This is not "a method of implementing", it's required behavior
    > > to meet iSCSI's architectural guarantee of command ordering.
    > > --
    > > Mallikarjun
    > > 
    > > Mallikarjun Chadalapaka
    > > Networked Storage Architecture
    > > Network Storage Solutions
    > > Hewlett-Packard MS 5668
    > > Roseville CA 95747
    > > cbm@rose.hp.com
    > > 
    > > 
    > > ----- Original Message -----
    > > From: "Eddy Quicksall" <Eddy_Quicksall@iVivity.com>
    > > To: "'Mallikarjun C.'" <cbm@rose.hp.com>; <ips@ece.cmu.edu>
    > > Sent: Monday, January 06, 2003 12:46 PM
    > > Subject: RE: iSCSI: Implicit Termination of Tasks
    > > 
    > > 
    > > > Yes, I noticed my typo of "two" vs. "three" but too late.
    > > >
    > > > Below you say that the ordering is iSCSI ordering but section 6.5 is
    > > saying
    > > > SCSI ordering (queued commands is SCSI). So, that leaves me a little
    > > > confused as to what this paragraph is trying to say, especially when
    > > the
    > > > "status is never communicated back ... to the initiator".
    > > >
    > > > I'm probably mis-understanding something. It appears as 
    > > though this is
    > > just
    > > > a method of implementing within the target.
    > > >
    > > > Eddy
    > > >
    > > > -----Original Message-----
    > > > From: Mallikarjun C. [mailto:cbm@rose.hp.com]
    > > > Sent: Monday, January 06, 2003 3:12 PM
    > > > To: Eddy_Quicksall@ivivity.com; ips@ece.cmu.edu
    > > > Subject: Re: iSCSI: Implicit Termination of Tasks
    > > >
    > > >
    > > > Comments below.
    > > > --
    > > > Mallikarjun
    > > >
    > > > Mallikarjun Chadalapaka
    > > > Networked Storage Architecture
    > > > Network Storage Solutions
    > > > Hewlett-Packard MS 5668
    > > > Roseville CA 95747
    > > > cbm@rose.hp.com
    > > >
    > > > ----- Original Message -----
    > > > From: "Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
    > > > To: <ips@ece.cmu.edu>
    > > > Sent: Monday, January 06, 2003 5:16 AM
    > > > Subject: iSCSI: Implicit Termination of Tasks
    > > >
    > > >
    > > > > There are two sections titled Implicit Termination of 
    > > Tasks but they
    > > > are
    > > > > slightly different. Which is correct?
    > > >
    > > > Both are correct and consistent.
    > > >
    > > > >
    > > > > Section 6.5 lists 4 items but section 10.14.5 only lists two.
    > > >
    > > > I'm seeing three in 10.14.5.....
    > > >
    > > > Even though 6.5 lists all the four cases, it makes it clear that the
    > > > check condition is to be employed only for three cases - and
    > > > only those three are listed by 10.14.5.  Perhaps the text could have
    > > > been a little bit more explicit about this distinction.
    > > >
    > > > >
    > > > > If 6.5 is correct, why is item D not included in the unit 
    > > attention?
    > > > SAM-3
    > > > > says:
    > > >
    > > > It's not so much a SAM issue.  The issue we considered was how to
    > > ensure
    > > > iSCSI-standard ordered delivery of commands in the face of errors.
    > > The
    > > > ordered delivery of commands does not make sense for case (d) - that
    > > of
    > > > creating a new session - ordering is not guaranteed anyway across
    > > > sessions.
    > > >
    > > >
    > > 
    > 
    


Home

Last updated: Wed Jan 08 12:19:08 2003
12136 messages in chronological order