SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [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