|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: response to second login (with same ISID)Jim Hafner wrote: > The current thinking is that an iSCSI initiator must use a different ISID > for each session it opens with a specific iSCSI target. Jim, Are you referring to multiple concurrent sessions from an initiator node to a given target port above in saying that different ISIDs must be used ? In the case where the initiator re-establishes a session to the same target port after a power cycle, it is desirable to re-use the same ISID, to allow for tracking of persistent reservation like properties, correct ? (Just checking to make sure the ISID semantics did'nt change since the Nashua discussion.) > We need to decide on the iSCSI target's response when the iSCSI initiator > attempts to break this rule. The choices are: > 1) REJECT the login with some error code (that the iSCSI initiator can > understand or infer to mean "ISID in use") and leave the pre-existing > session alone > 2) CLOSE the pre-existing session (and abort all it's tasks) and then > process the new login fresh. > > Personally, I have no strong feeling either way, but lean towards option > (1). It's simple, clean and doesn't involve any interruption. I'd vote for (2) for the following reasons : a) It is possible for initiators to use the ISID as a scheme to establish persistence of their O.S. device files. In doing so, initiators would attempt to obtain the same ISID for a given session to a given target ports across boots. (and rightly so, for enabling targets to track persistent reservation like properties, etc). In the event where the initiator went through a non-orderly shutdown which did not close all sessions, it would attempt to re-login on re-boot with the same ISID. If the target rejected this re-login, per (1) (citing an invalid ISID), the initiator would no longer be able to maintain persistence of the session to an ISID. b) Using (2) allows the hosts to hint to the target that the previous session is now stale and thus triggers clean-up of stale session resources. Regards, Santosh begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard
Home Last updated: Tue Sep 04 01:04:39 2001 6315 messages in chronological order |