SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Several iSCSI protocol questions




    I already answered to this.

    This is a result of using ITT for everything.

    We considered it several times (adding a reject code) but the we thought that
    the "good side-effects" outweight the bad (e.g., you can do a TASK SET CLEANUP including an TASK ABORT) and it is not worth adding reject code (mainly not worth testing for it).  I fail to see a scenario where it can do unintentional harm.

    Julo


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

    30/08/02 17:58

           
            To:        tonyb@cybernetics.com, ips@ece.cmu.edu
            cc:        
            Subject:        RE: Several iSCSI protocol questions

           


    > > > Since the Task Management Function itself has a CmdSN and
    > > > valid LUN, can one
    > > > Task Management Function affect (abort) another?
    > >
    > > No, SCSI task management functions operate on *SCSI* tasks, not *iSCSI*
    > > tasks, and a task management function is not a *SCSI* task - see SAM-2.
    >
    > This contradicts the text in Section 9.5.1: "The Task Management functions
    > provide an initiator with a way to explicitly control the execution of one
    > or more Tasks (SCSI and iSCSI tasks)."  Your interpretation makes more
    sense
    > to me, however.

    And there's more text further down in 9.5.1 that seems to imply that
    one ought to be able to abort a Task Management Function.

     All these functions apply to the referenced tasks regard-
     less of whether they are proper SCSI tasks or tagged iSCSI opera-
     tions.

    I think you've caught something we need to fix ...

    > > > If not, then what is the
    > > > appropriate Task Management Function Response for an ABORT TASK that
    > > > attempts to operate on another Task Management Function?
    > >
    > > That can't happen.  The only task management function that could
    possibly
    > > attempt "to operate on another Task Management Function" is ABORT TASK,
    but
    > > it identifies the task to be aborted by an Initiator Task Tag, something
    > > that Task Management Functions *do not* have - see Section
    > > 9.5 of the iSCSI draft.
    >
    > I am looking at Section 9.5.  I see "Initiator Task Tag" in the table
    > showing the PDU format, although it is not mentioned in the
    > text.  Another typo?

    My mistake - I think we have some text cleanup to do, as SAM-2 definitely
    considers task management functions not to be tasks, thus avoiding issues
    of what happens when a task management function is applied to a task
    management function - I believe iSCSI needs to follow this route.  Julian?

    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: Fri Aug 30 13:18:55 2002
11725 messages in chronological order