|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: target reset revisitedMallikarjun, 1 Abort Task---aborts the task identified by the Referenced Task Tag field. 2 Abort Task Set---aborts all Tasks issued by this initiator on the Logical Unit. 3 Clear ACA---clears the Auto Contingent Allegiance condition. 4 Clear Task Set---Aborts all Tasks (from all initiators) for the Logical Unit. 5 Logical Unit Reset 6 Target Warm Reset 7 Target Cold Reset Satran Standards-Track, May 2001 26 iSCSI December 4, 2000 For the functions above a SCSI Task Management Response MUST be returned, using the Initiator Task Tag to identify the operation for which it is responding. "Mallikarjun C." <cbm@rose.hp.com> on 12/12/2000 01:00:56 Please respond to cbm@rose.hp.com To: ips@ece.cmu.edu cc: Subject: iSCSI: target reset revisited Julian, To my surprise, I am finding that the latest iSCSI draft still does not require a response on a target reset. We agreed in a previous email conversation on this list, that the "warm" version of the target reset requires a task management response. I attach the email for reference. I assume it is a typo and would be corrected in the next version. Thanks. -- Mallikarjun Mallikarjun Chadalapaka M/S 5601 Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard, Roseville. cbm@rose.hp.com From: julian_satran@il.ibm.com X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: <C1256951.005EE23C.00@d12mta02.de.ibm.com> Date: Tue, 5 Sep 2000 20:14:17 +0300 Subject: Re: Target Reset handling Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Status: RO X-Status: X-Keywords: X-UID: 827 Mallikarjun, Is the C bit hidden in the CDB? We as a rule avoided examining the CDB (iSCSI never has to). If we can make it external then we are in wild agreement. Regards, Julo "Mallikarjun C." <cbm@rose.hp.com> on 05/09/2000 20:03:56 Please respond to cbm@rose.hp.com To: ips@ece.cmu.edu cc: (bcc: Julian Satran/Haifa/IBM) Subject: Re: Target Reset handling 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:06:06 2001 6315 messages in chronological order |