SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Target Reset handling (fwd)



    Apologies if this is a second copy, I had not seen my copy of
    this posting or on the web archive even after more than an hour....
    --
    Mallikarjun 
    
    
    Forwarded message:
    
    Date: Tue, 05 Sep 2000 10:03:56 PDT
    To: ips@ece.cmu.edu
    Subject: Re: Target Reset handling
    In-Reply-To: <C1256950.001C76C2.00@d12mta02.de.ibm.com>; from "julian_satran@il.ibm.com" at Sep 4, 100 8:08 am
    Status: RO
    
    Julian,
    
    Thanks for the suggestion.
    
    I am in broad agreement with this kind of definition, if the 
    rest of the folks accept it.  I would however suggest a single
    Target Reset task management function (in accordance with SAM-2),
    and provide the choice of a "cold-reset" with a "C" bit in the 
    Task Management Command PDU.  Assuming that we do this, let me 
    try to summarize our tentative agreement:
    
    o Target Reset task management requires a response, unless the
      the C-bit is set in which case the sessions would be terminated
      as well and no response can be expected.
    
    o A Unit Attention AER shall be reported to all currently logged-in
      initiators, in accordance with the provisions contained in clauses
      7.9 and 8.3.6 of SPC-2 (basically, to be reported only if agreed
      in advance between the initiator and the LU).
    
    Regards.
    --
    Mallikarjun 
    M/S 5601			
    Networked Storage Architecture
    HP Storage Organization
    Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    
    >Mallikarjun,
    >
    >How about having two different function:
    >
    >target warm-reset (connections stay) and target cold-rest (connections get
    >also reset)?
    >
    >Julo
    >
    >"Mallikarjun C." <cbm@rose.hp.com> on 03/09/2000 06:07:07
    >
    >Please respond to cbm@rose.hp.com
    >
    >To:   ips@ece.cmu.edu
    >cc:    (bcc: Julian Satran/Haifa/IBM)
    >Subject:  Re: Target Reset handling
    >
    >
    >
    >
    >Julian,
    >
    >Let me try again, I was arguing that the protocol stack (I assume you
    >mean the state information in various layers by this) and the TCP
    >connections be *not* reset - since I do not see a need for the SCSI
    >transport mechanism to be reset/cleared in the context of "SCSI target
    >reset".  I would again request your attention on the FC precedent, and
    >the software expectations of a confirmed target reset.  Logging in after
    >an arbitrary "long time" and assuming the target reset to be complete is
    >simply unreliable.
    >
    >I do not see a need for a special "iSCSI reset".  I believe that the
    >SCSI target reset task management request is completely adequate to
    >address our requirements.  All I am proposing is a change in its current
    >definition in view of the various reasons I had already stated, and the
    >benefits of making this change (not the least of which is SAM-2
    >compliance).  Addition of a new reset mechanism would also defeat our
    >common goal to keep a fairly lean protocol.
    >
    >The question of security context needs to addressed regardless of the
    >SCSI transport behavior on a target reset.  If security context is being
    >designed as part of the transient operating environment (as opposed to
    >say, creating/modifying mode pages), then my first guess would be that
    >it has to be reset as well to initial values, on a target reset.  I am
    >not sure what you implied, but are you suggesting that the security
    >context cannot be reset with TCP connections living across a SCSI target
    >reset?  Or, did I totally miss something?
    >
    >Regards.
    >
    >Mallikarjun
    >M/S 5601
    >Networked Storage Architecture
    >HP Storage Organization
    >Hewlett-Packard, Roseville.
    >cbm@rose.hp.com
    >
    
    
    


Home

Last updated: Tue Sep 04 01:07:35 2001
6315 messages in chronological order