|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: clearing SCSI objectsDavid, I'm wondering what other targets are doing about this. Was it thought about during the design phase? I'm thinking I will keep an LRU list and if I run out of structures to handle SCSI Initiator Ports (and there are no persistent reserves outstanding), I'll just discard the oldest structure. That will give a power on reset UA if that InitiatorName+ISID is used again. Does that seem like a logical solution? Eddy -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, May 02, 2003 9:44 AM To: Mallikarjun C.; ips@ece.cmu.edu Subject: RE: iSCSI: clearing SCSI objects Thanks for making me more aware. Actually what I'm looking for is a sure fire way I can release resources for a SCSI Initiator Port (InitiatorName+ISID) after session closure (assuming there are no outstanding persistent reservations). Understanding "I_T Nexus Loss" better brings up another point regarding this: Section 6.3.4 of SAM-3R6 says that the target shall establish a unit attention for the SCSI initiator port. But the SCSI initiator port is identified via the ISID. That means after a session closure (in my case via a session logout), the target needs to still keep state information for each ISID that was ever used. That can be a burden on the target's resources. Especially if the initiator device uses a different ISID for each login. Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Thursday, May 01, 2003 9:21 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: clearing SCSI objects >But if the > default versions apply to ErrorLevel 0, that is exactly what I want. Careful here, the default versions apply to any level when there's no explicit Logout dialogue (refer 6.4.1). > Also, paragraph 12.16 does not talk about exceeding DefaultTime2Retain > causing an I_T Nexus Loss notification Because exceeding (DefaultTime2Wait+DefaultTime2Retain) does not necessarily always cause an I_T Nexus Loss, refer 5.3.5.1 for what does. > Can you confirm that the following would be correct? Correct if that's a single-connection session. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Hewlett-Packard MS 5668 Roseville CA 95747 cbm@rose.hp.com ----- Original Message ----- From: "Eddy Quicksall" <eddy_quicksall@ivivity.com> To: "Mallikarjun C." <cbm@rose.hp.com>; <ips@ece.cmu.edu> Sent: Thursday, May 01, 2003 6:07 PM Subject: RE: iSCSI: clearing SCSI objects > Thanks, that was the missing link I think ... I thought since > DefaultTime2Wait & DefaultTime2Retain were only for ErrorLevel 2 because > that is said in the logout regarding Time2Wait and Time2Retain. But if the > default versions apply to ErrorLevel 0, that is exactly what I want. > > Also, paragraph 12.16 does not talk about exceeding DefaultTime2Retain > causing an I_T Nexus Loss notification (which is the only iSCSI thing that > can clear a SCSI object). > > Can you confirm that the following would be correct? > > - I negotiate for ErrorLevel 0 > - I negotiate for DefaultTime2Wait and DefaultTime2Retain = 0 > - I get a logout > - I clear all SCSI objects other than the ones you mention below. > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Thursday, May 01, 2003 8:34 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: clearing SCSI objects > > > First, am I correct in the above? > > Not completely. If there are no active FFP connections > in the iSCSI session, the session will eventually come to > an end ([Default]Time2Wait/Return). That is when the > associated I_T Nexus Loss notification is generated, and > with it, all the SCSI objects that are considered attributes of > that instance of I_T Nexus are cleared. > > Note however that there may be SCSI objects that are > not linked to the life of an instance of I_T Nexus - this is > a SCSI issue (and F.2 does refer to it). > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions > Hewlett-Packard MS 5668 > Roseville CA 95747 > cbm@rose.hp.com > > ----- Original Message ----- > From: "Eddy Quicksall" <eddy_quicksall@ivivity.com> > To: <ips@ece.cmu.edu> > Sent: Thursday, May 01, 2003 11:58 AM > Subject: clearing SCSI objects > > > > I have a concern regarding a logout followed by login's with a different > > ISID from the same initiator device. > > > > Here is my concern: > > > > - the target must keep state information for the initiator port > > after a logout (such as a reservation - but not limited to that). This is > > because section F.2 says only an I_T Nexus Loss can effect clearing > actions > > on SCSI objects. > > - If a target receives a logout, then another login from another > > initiator (or even another login from the same initiator device but a > > different ISID) then it must have resources available because it can't > clear > > the SCSI objects from the logged out session. > > - The resources can become stale and the target could run out of > > resources. > > > > First, am I correct in the above? If not please explain. > > > > If this is correct, I have not found anything in the spec that says how > long > > the SCSI objects must be kept around. > > > > Eddy > > > > >
Home Last updated: Mon May 05 19:19:26 2003 12572 messages in chronological order |