SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: TMF valid on all iSCSI taks? ( Was: Several iSCSI protocol questions)



    The intent consistently expressed in the draft is that all iSCSI tasks
    are the same in that they are "managed" by the same task management 
    functions (proposed exceptions below) - some iSCSI tasks are also SCSI 
    tasks as a co-incidence.  Technically, I thought we had concluded in
    the past that, one could use Abort Task TMF to abort Text Requests as well
    (and that's reflected in 2.2.2.1, second para).  I think this is one of 
    the core ideas in the draft, and not worth risking a last minute change.
    
    Tony caught a scenario that however, I think, merits an explicit clarification in 
    the draft - due to the inherent ambiguity in delivering an Abort Task
    TMF to the SCSI layer that's directed at an abort operation already 
    being carried out by the SCSI layer (What does a successful completion 
    of the second abort mean to the original task state?  Should the first
    Abort response be sent back or not?).  OTOH, there's no ambiguity
    for the Task Set management case, because one knows that all the tasks
    are dead once the TMF completes (SCSI tasks, iSCSI "abort" 
    tasks, everything).
    
    I suggest that we add a clarification for the "Abort-of-Abort" case, and 
    a couple of others (one of which is currently covered in 9.10) in one 
    new subsection.
    
    ----------------------------------------------------------------------------
    9.5.7 Exceptions to Task Management Function Request usage
    
    The following two exceptions apply to the usage of iSCSI Task Management
    functions defined earlier in the document.
    
           a) The ABORT TASK task management function request MUST NOT
            be directed at a prior iSCSI task performing an ABORT TASK task 
            management function request.
    
           b) The TASK REASSIGN task management function request MUST 
           NOT be used to reassign the connection allegiance of an active text 
           negotiation task, or a Logout task.
    ------------------------------------------------------------------------------
    
    If we do this, we'd have to 
    
        - Have the "any iSCSI task" language in section 2.2.2.1, second para to
           point to the new 9.5.7, to make the reader aware of the exceptions.
        - ditto for the first sentence in 9.5.1.
        - ditto for the "All these functions apply..." sentence later in 9.5.1 that 
           David identified.
    
    Comments?
    --
    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: <tonyb@cybernetics.com>; <ips@ece.cmu.edu>
    Sent: Friday, August 30, 2002 7:58 AM
    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: Sat Aug 31 02:18:52 2002
11734 messages in chronological order