SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: aborting an immediate command with ABORT TASK




    I don't think we want to. The TM made immediate are done so with good reason - to allow expedited consideration.
    And there are no known scenarios (to us) in which it does not work.

    Julo


    Eddy Quicksall <eddy_quicksall@ivivity.com>
    Sent by: owner-ips@ece.cmu.edu

    05/09/02 15:46

           
            To:        "'Black_David@emc.com'" <Black_David@emc.com>, tonyb@cybernetics.com
            cc:        ips@ece.cmu.edu
            Subject:        RE: iSCSI: aborting an immediate command with ABORT TASK

           


    Can we say that aborts with the immediate bit only abort commands with the
    immediate bit? And then say that the window is not advanced under that
    situation?

    Eddy

    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Thursday, September 05, 2002 2:51 AM
    To: tonyb@cybernetics.com
    Cc: ips@ece.cmu.edu
    Subject: RE: iSCSI: aborting an immediate command with ABORT TASK


    This thread's taken a while to sort through, but there
    does appear to be a problem in here.

    > If the missing command was non-immediate, then yes, the plug-in avoids
    > having to resend the missing command.  But, if the missing command was
    > immediate, then there is no hole to plug.  In this case, the spec requires
    > the target to plug a hole which does not exist, which is the problem that
    I
    > am trying to point out.

    I'm working off of -15.  Section 2.2.2.1 contains the following statements:

                    CmdSN always contains the number to be
         assigned to the next Command PDU.

      Commands meant for immediate delivery are marked with an immediate
      delivery flag; they MUST also carry the current CmdSN.

    So suppose CmdSN is 7, and the initiator sends an immediate command
    with CmdSN 7 and then decides to abort it, and sends TASK ABORT as
    an immediate command (CmdSN is 7 and not advanced).  Suppose the TASK
    ABORT crosses the response to successful completion of the immediate
    command on the wire.  At this point the following text in Section
    9.6.1 applies:

        b)  if the Referenced Task Tag does not identify an existing task
        but if the CmdSN indicated by the RefCmdSN field in the Task Man-
         agement function request is within the valid CmdSN window (between
         MaxCmdSN and ExpCmdSN), targets must consider the CmdSN received
         and return the "Function complete" response.

    7 is still the CmdSN of the next non-immediate command to be sent,
    so it is within the window (ExpCmdSN is also 7).  Following these
    directions, the Target considers CmdSN 7 to be received, and advances
    its window.  Now, when the initiator sends its next non-immediate
    command (CmdSN=7), its CmdSN is outside the window, and the target
    bit-buckets the command instead of executing it.

    This went awry because the task to be aborted was (implicitly)
    identified by its CmdSN, and not its Task Tag resulting in an attempt
    to abort an immediate command actually clobbering the next non-
    immediate one.  I think Tony gets credit for finding another problem.

    While I'm in here, it also appears that the text describing the
    mapping of iSCSI task management response codes to SCSI service
    responses needs to change to map 1 (Task does not exist) to
    FUNCTION COMPLETE rather than FUNCTION REJECTED to line up with
    Section 6.2 of SAM-2.

    Thanks,
    --David
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449            FAX: +1 (508) 497-8018
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------




Home

Last updated: Thu Sep 05 09:18:55 2002
11764 messages in chronological order