SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Task Management



    Do you think that T10 should clarify the semantics of a 
    target reset (beyond whether or not the connection -
    or really the session is dropped)?. I agree with you that
    if there is a "view" of the storage (as expressed by the
    LUNs exposed to an initiator), then "target reset" should
    apply to that view - and to all initiators connected to
    that view through all the different paths to that view.
    
    There will then be the confusion of what happens if two
    "views" have intersection of LUNs.
    
    > -----Original Message-----
    > From: Prasenjit Sarkar/Almaden/IBM [mailto:psarkar@almaden.ibm.com]
    > Sent: Friday, October 13, 2000 1:54 PM
    > To: ips@ece.cmu.edu
    > Subject: iSCSI: Task Management
    > 
    > 
    > 
    > I dont know whether this has been raised before.
    > 
    > With reference to the Task Management section of the 
    > document, it is my
    > opinion
    > that the target reset function from an initiator should be 
    > limited to the
    > LUNS
    > exposed to that initiator, and the connections to only that 
    > initiator be
    > closed.
    > The motivation is that an initiator with access to a single 
    > LUN should not
    > be
    > able to bring down an entire target device with 1000s of LUs. From my
    > experience,
    > there are enough buggy initiators which can generate target 
    > resets at the
    > first chance.
    > 
    > Implementors may control Target Reset behavior with Jim 
    > Hafner's access
    > control
    > stuff in T10.
    > 
    > Sincerely,
    > Prasenjit
    > 
    > 
    > --------------------------------------------------------------
    > --------------------------------------------------------------
    > -------------------------------------------------------
    > 
    > <!--StartFragment-->3.7.1.  Function
    > 
    >      The Task Management functions provide an initiator with a way to
    >      explicitly control the execution of one or more Tasks. The Task
    >      Management functions are summarized as follows (for a 
    > more detailed
    >      description see the [SAM2] document):
    >           1    Abort Task---aborts the task identified by the 
    > Referenced
    >                Task Tag field.
    >           2    Abort Task Set---aborts all Tasks issued by 
    > this initia-
    >                tor on the Logical Unit.
    >           3    Clear ACA---clears the Auto Contingent 
    > Allegiance condi-
    >                tion.
    >           4    Clear Task Set---Aborts all Tasks (from all initiators)
    >                for the Logical Unit.
    >           5    Logical Unit Reset.
    >           6    Target Reset.
    >      For the functions above except <Target Reset>, a SCSI 
    > Task Manage-
    >      ment Response is returned, using the Initiator Task Tag 
    > to identify
    >      the operation for which it is responding.  For the <Target Reset>
    > 
    > 
    > 
    > Satran, Smith, Sapuntzakis, Meth                              
    >  [Page 23]
    > 
    > iSCSI                         June 2000
    > 
    > 
    >      function, the target cancels all pending operations. The 
    > target may
    >      send an Asynchronous Event to all attached initiators notifying
    >      them that the target is being reset.  The target then 
    > closes all of
    >      its TCP connections to all initiators (all sessions are ter-
    >      minated).
    > 
    > 
    > <!--EndFragment-->
    > 
    > 
    > 
    > 
    > 
    >    Prasenjit Sarkar
    >    Research Staff Member
    >    IBM Almaden Research
    >    San Jose
    > 
    


Home

Last updated: Tue Mar 26 16:18:20 2002
9313 messages in chronological order