|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Target Reset handlingMallikarjun, 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:07:35 2001 6315 messages in chronological order |