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



    One could make the argument that a "big hammer" reset is desireable,
    especially in new implementations that might hang - the initiator could
    attempt to "power cycle" the box if it hangs.  The problem is that at this
    reset is at a really high level (the iSCSI/TCP/IP stack must be working in the
    first place to even receive and process the command). FC loop defined a "link
    primitive" that could be used the reset the entire device (the LIP_RESET) that
    required only the lowest level link primitive state machine to be running to
    process it - and yank on a global reset line.  If iSCSI/TCP/IP is in a state
    that it can receive and decode the "big hammer" reset iSCSI PDU, I don't think
    it would be in a state that it needs to be reset.
    
    -Matt Wakeley
    Agilent Technologies
    
    Robert Snively wrote:
    
    > I do not believe that the added complexity of a cold and hot
    > reset is appropriate.  SCSI-2 had such a concept, and it was ultimately
    > determined that there was no benefit to it, and the complexity was
    > immense.
    >
    > I strongly feel that the SCSI Target Reset should do exactly
    > no more and no less than the corresponding function does in all
    > other SCSI devices.
    >
    > If a session/connection reset is required, it should be performed
    > by session/connection control mechanisms already defined by TCP/IP.
    > Its effect on the SCSI target should be defined, but may or may
    > not be the same as the SCSI Target Reset. FCP-2 provides some examples
    > of the kind of things that you may choose to reset in table 4.
    >
    > No "C" bit should be used.
    >
    > The session/connection reset should not be in the CDB or in the
    > task management functions.
    >
    > Bob
    >
    > >  -----Original Message-----
    > >  From: Mallikarjun C. [mailto:cbm@rose.hp.com]
    > >  Sent: Tuesday, September 05, 2000 11:14 AM
    > >  To: ips@ece.cmu.edu
    > >  Subject: 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:34 2001
6315 messages in chronological order