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



    A few comments on this thread:
    
    * Autosense protocols simply do not have CA.  At the T10 CAP meeting
    this week, Ralph Weber is proposing removing all references to CA from
    SAM-3 (see 03-002r2 on http://www.t10.org).  As soon as a command
    completes, it is assumed that the status and sense data will be returned
    together.  If they can't be delivered, it doesn't matter.
    
    * the clearing effects table in FCP-2 was removed because it had several
    incorrect entries and was missing quite a few additional SCSI items that
    are also affected by logouts.  T10 proposals 02-143r3 and 02-232r2 have
    the details and include large tables listing all the considered SCSI
    effects.  These proposals have been incorporated into the latest SAM-3,
    SPC-3, SBC-2, and SSC-2 standards.
    
    * Most protocols don't detail how their hypothetical SCSI layer confirms
    the abort of tasks to the protocol layer by specifying a CHECK
    CONDITION, much less one with a specific sense key and additional sense
    code.  This level of detail is internal only and seems irrelevent to the
    iSCSI wire protocol. Specifying a "unit attention" sense key could cause
    particular confusion, since unit attentions are supposed to be cleared
    once reported.  
    
    On the iSCSI wire, the goal is to generate a unit attention with an
    additional sense code whose ASC field is 29h (e.g. I_T NEXUS LOSS, POWER
    ON OCCURRED, etc.) on the next command.
    
    To minimize changes to iSCSI at this point, I recommend changing
    the wording like this (changed text noted between _ characters)
    so only status is mentioned and it is only mentioned as an example:
    
    If the tasks terminated in the above cases a), b, c) and d)are SCSI
    tasks, they must be internally terminated _with CHECK CONDITION
    status with a sense key of unit attention and ASC/ASCQ values of
    0x6E/0x00 (COMMAND TO LOGICAL UNIT FAILED)_. This status is only
    meaningful for appropriately handling the internal SCSI state and
    SCSI side effects with respect to ordering (e.g., queued commands
    and ACA) because this status is never communicated back as a
    terminating status to the initiator.
    
    To:
    If the tasks terminated in the above cases a), b, c) and d) are SCSI
    tasks, they must be internally terminated _as if with CHECK CONDITION
    status_.  This status is only
    meaningful for appropriately handling the internal SCSI state and
    SCSI side effects with respect to ordering (e.g., queued commands
    and ACA) because this status is never communicated back as a
    terminating status to the initiator.
    
    ---
    Rob Elliott, HP Industry Standard Server Storage
    elliott@hp.com 
    
    -----Original Message-----
    From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] 
    Sent: Thursday, January 09, 2003 2:39 PM
    To: dcuddihy@attotech.com; ips@ece.cmu.edu
    Subject: RE: iSCSI: Implicit Termination of Tasks
    
    
    The way I figured it would work is that the UA would get set and would
    get reported when the next command arrives.
    
    Consider this:
    
    connection 0 and 1 are all quite
    connection 0 has a command x on the wire
    connection 0 is lost
    the UA is set
    command y comes in connection 1
    command y gets the UA or ACA Active
    
    That way the upper layer at the initiator can figure out how to recover.
    
    Is this not the idea?
    
    Eddy
    
    -----Original Message-----
    From: dcuddihy@attotech.com [mailto:dcuddihy@attotech.com]
    Sent: Thursday, January 09, 2003 3:05 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI: Implicit Termination of Tasks
    
    
    David,
    
    Regarding Autosense clearing the CA:
    
    The problem that I have with this is that the CA should get cleared when
    the sense data is reported, not when the sense data is generated.  In
    this case, the autosense cannot be reported (the port is logged out), so
    the CA may not be cleared. It doesn't seem to me that generating a sense
    data response, even for an interface in which autosense is mandatory,
    implicitly clears a CA.
    
    By the way, there was a question of Request Sense commands enqueued when
    a termination occurs .. my understanding is that the sense data need not
    be saved for a subsequent request sense command if it has been reported
    via autosense, so the request sense returns NO_SENSE.
    
    Regarding FCP handling of port logout and ACA:
    
    For us, ACA is a non-issue-- we don't support it, but it should be
    cleared only for the initiator which generated the log event.  (ACA
    support seems to be a point of contention among SCSI implementers... I
    know it's in all the specs, but I have yet to see it implemented.)
    
    Rev 7A of FCP-2 has a nice chart of how task managment is affected via
    the various log events.  I'm not why it was removed in rev 8, but "FCP-2
    Rev 7A (1/1/2001)" Table 4 might help.
    
    regards,
    
    david
    
    
    
    
    David J Cuddihy
    Principal Engineer
    ATTO Technology, Inc.
    http://www.attotech.com/fcbridge.html
    dcuddihy@attotech.com
    
    ------------------------------------------------------------------------
    ----
    ---------------------
    
    
    ------------------------------------------------------------------------
    ----
    ---------------------
    
    David,
    
    > Forgive me for being confused, but what is the reason for the Check 
    > Condition being issued?
    
    Good question ...
    
    > Say a target implements a blocking CA, (TST 0 Qerr 0) which would
    disallow
    > other initiator's tasks from running until the check condition could 
    > be reported, or another command from the CA'd initiator completes with
    
    > good status.  An internal, non- reported check-condition would cause 
    > all other initiators' tasks to be blocked until  someone times out and
    
    > issues a lun reset to the device, or a command from the first 
    > initiator completed (not likely, since that initiator logged out and
    all its tasks have been
    > terminated ).    All this caused by bad behavior on behalf of one
    > initiator.
    
    That shouldn't happen.  iSCSI REQUIRES use of Autosense, which will
    immediately clear the CA by generating a response to report the sense.
    That response gets bit-bucketed as undeliverable for the implicit
    termination scenarios in Section 6.5, but its generation clears the CA.
    Not the most obvious thing to do/explain, though ...
    
    > Implicit termination is handled in FCP without the check condition 
    > being issued... all the tasks from the 'logged out' initiator are 
    > terminated, reservations cleared, etc.  and a UA is generated for that
    
    > initiator. Every other initiator goes along with no problem, including
    
    > those sharing the lun with the initiator who abruptly logged out.  
    > Seems to work.
    
    That looks like a cleaner way to accomplish this and avoids some of the
    confusion over what ASC/ASCQ values to use.  Does FCP also avoid ACA in
    this circumstance (assuming that NACA is set to use ACA), and if so, can
    you suggest some specific text for iSCSI?
    
    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: Tue Jan 14 04:19:30 2003
12165 messages in chronological order