|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Target Reset handlingOne 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 |