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




    the cross I_T Nexus is spatial not temporal.  
    If you have a single session - then there is nothing you have to do.

    Julo


    Black_David@emc.com
    Sent by: owner-ips@ece.cmu.edu

    08/01/03 18:36

    To
    cbm@rose.hp.com, ips@ece.cmu.edu
    cc
    Subject
    RE: iSCSI: Implicit Termination of Tasks





    Mallikarjun,

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

    While I understand the intent, the problem is that CHECK CONDITION is
    a SCSI mechanism that SAM-2 now defines to have cross-I_T nexus
    (cross-session) side effects in some cases - iSCSI cannot disregard
    those side effects because they're inconvenient, and hence if CHECK
    CONDITION is used with implicit task termination, it ought to be
    used consistently.

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

    The problem with this is that CHECK CONDITION is of interest to the
    SCSI layer by definition, and the potential cross-I_T nexus side
    effects make case (d) relevant to SCSI in a way that it was not earlier.

    I have a problem when the answer to:
                    "When iSCSI loses or tears down connectivity, do implicitly
                    terminated tasks generate CHECK CONDITION and its potential
                    cross-I_T nexus side effects?"
    is:
                    "It depends on how the connection was torn down or lost."
    because to my mind that's much worse than "yes" or "no".
    While it may have no bearing on the ordering guarantee, the different
    results for the TST=0 case will be a major surprise, especially if ACA
    is in use.

    FWIW, the cross-nexus side effects were added to SAM-2 in the relatively
    recent past - as SAM-2 was when much of the work on iSCSI was done, the
    current state of iSCSI would be fine as there would have been no way
    to determine whether the internal CHECK CONDITION was generated in
    case (d) once the I_T nexus (iSCSI session) vanished.  T10 decided
    to change that situation, and we need to cope with this consequence.

    > 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

    I have a note in to Rob Elliott asking the scope of the current ASC/ASCQ
    value can be expanded.  Let's make sure that it can't be before making
    this sort of annoying minor change at this stage.

    Thanks,
    --David
    ----------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 176 South St., Hopkinton, MA  01748
    +1 (508) 293-7953 **NEW**     FAX: +1 (508) 293-7786
    black_david@emc.com        Mobile: +1 (978) 394-7754
    ----------------------------------------------------



Home

Last updated: Wed Jan 08 14:19:02 2003
12139 messages in chronological order