|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Target Reset handlingMallikarjun, 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 julian_satran@il.ibm.com wrote: > > Mallikajun, > > Assuming that we leave the connections on - how would you suggest we reset > the protocol stack and the connections? > > Is adding a new iSCSI reset better? > > Should the target imply a reset when all connections drop and a new session > get's established or a long time passes? > > What happens to the security context across a reset? > > I have the feeling that answers to those questions will complicate the > reset handling > far beyond what the technical community will find acceptable. > > Julo > > "Mallikarjun C." <cbm@rose.hp.com> on 01/09/2000 20:31:39 > > Please respond to cbm@rose.hp.com > > To: ips@ece.cmu.edu > cc: (bcc: Julian Satran/Haifa/IBM) > Subject: Re: Target Reset handling > > Julian, > > I agree with you that the interactions should be left as simple > as possible, but I strongly believe that a response to a target > reset is highly desirable and very useful. Besides, my reading > of SAM-2 (as quoted below) indicates that a response is required. > > While SAM-2 leaves the definition of the target reset process to > the specific SCSI protocol and interconnect, I would argue that in > the case of iSCSI, resetting the entire TCP/IP stack and tearing > up the TCP connections should not be necessary. It would seem that > the SCSI operational portion (task manager, device server(s), and > the tasks themselves) should be affected by a SCSI target reset. > As I recall, this is the approach FC target implementations took > leaving the process login sessions intact. Having the TCP connections > operational would allow us to - > - reliably deliver the AEN to all the iSCSI-logged-in initiators. > - deliver a response to target reset task mgmt request > > There's a fair amount of SCSI/LVM software that relies on a reliable > target reset confirmation, and an out-of-band confirmation of the > same would not go well with it. > > Regards. > -- > Mallikarjun > M/S 5601 > Networked Storage Architecture > HP Storage Organization > Hewlett-Packard, Roseville. > cbm@rose.hp.com > > >Mallikarjun, > > > >We assumed that a reset for a controller including such a complex piece > >of code/hardware as protocol stack is never complete without resetting it > >too. > >making AE signalling mandatory is not big help as they might get lost > >if done before the connections break. But if the group feels we should > make > >it mandatory we will. > > > >For any simple minded (minimalist design) a protocol function > >that does what a reset button would do should be enough. > > > >For complex controllers you can choose to: > > > >- record the reset results in NV store and report them during the next > >session > >or even make reading this log in a sense mandatory through an ACA > > > >- report the event through a vendor specific text response to the next > >login > > > >- use management interfaces (SNMP) > > > >I personally am inclined to think that the "in-band" rest should be left > >as simple as possible (but not simpler!) and out-of-band communication > >should > >be used to check the process. > > > >Regards, > >Julo > >
Home Last updated: Tue Sep 04 01:07:35 2001 6315 messages in chronological order |