SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: reusing ISID for recovery



    
    Julian,
    
    You wrote:
        to management servers that direct you to same target under two
    different names
    
    I didn't understand who has the different name, the target or the
    initiator.  In either case, however, it doesn't matter because the ISID
    scoping is within the *named* pair of (initiator,target), so that there
    won't be a collision!
    
    Jim Hafner
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/29/2001 10:33:35 PM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: reusing ISID for recovery
    
    
    
    
    With  regard to time bloat I have two things to say:
    
    1- It is a rare event (connection don't stay alive long if a machine goes
    down)
    2 - we could remove the checking - going only on reporting and have in
    those cases the command reissued with X
    
    As for the mistake I am afraid that anything that is so easy to do badly
    will be done badly and causes can range from simple bugs, to management
    servers that direct you to same target under two different names and the
    target does not care to two user programs doing uncoordinated login (but
    only one is bad).
    
    I assume that are many scenarios that we don't even think about.
    
    My long experience tells me not make it easy for a mistake to ruin good
    work.
    
    And I think that the proposal that is out (removing the checking and having
    Marjory irritated) is a good compromise between simplicity a sound
    engineering.
    
    Julo
    
    
    Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 30-08-2001 02:54:09
    
    Please respond to Santosh Rao <santoshr@cup.hp.com>
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: reusing ISID for recovery
    
    
    
    Julian Satran wrote:
    
    > Doing an automatic logout when a new session is seen can be performed by
    > mistake by an OS in a multi OS machine. It is just to easy to let it
    > through.
    
    A multi-OS system would use a different iSCSI initiator name for each O.S.
    
    
    > After a reboot the right procedure would be to login cleanly (no
    > previous knowledge needed). The target will ascertain that the old
    session
    > is dead and let you in.
    
    Are you suggesting a combination of the existing login target behaviour
    wherein the target checks the olde session if it exists when the X bit is
    not
    set, coupled with an unconditional cleanup when the X bit is set ?
    
    Having the target test the old session, prior to responding to a login can
    bloat login time to unacceptable levels and increase system bootup time as
    well as I/O scan time.
    
    
    >
    > You will need the X only when the old session is alive (answering to NOP)
    > but you don't know how to clean it.
    
    The initiator may not know if an old session had been established by it
    previously. Hence, it will either always need to set the X bit, or risk the
    chance of a login reject.
    
    What are we trying to achieve by having the target validate the initiator's
    attempt to clean up an old session ? The target must trust the initiator's
    decision to clean up [after first completing login authentication to avoid
    malicious logout type attacks], rather than have to validate it first.
    Targets
    should not be expected to do all this extra work of validation to protect
    against initiator coding bugs.
    
    The draft should not be trying to optimize for a coding bug scenario,
    wherein
    the initiator accidentally re-logs in with the same (iscsi initiator name,
    ISID, NULL TSID).
    
    FC exhibits the same semantics that are being asked for here. Implicit
    logout
    + re-login behaviour is oft used by FC initiators. Similar login semantics
    will make the life of iscsi-fc convertor products easier as well.
    
    
    >
    > Reboot behavior is close to what you have in the current draft ( a single
    > login needed - no X).
    
    On a reboot, the initiator does not know if it has previously logged out of
    the session prior to the reboot. Thus, it would need to clean up any stale
    sessions, if they exist. Rather than attempt 2 logins [one with an X and
    then,
    one without], the login should be allowed to imply a logout of any stale
    session, if one such exists.
    
    This issue is applicable to the reboot of initiators.
    
    - Santosh
    
    >
    > "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
    @ece.cmu.edu
    > on 29-08-2001 22:27:35
    >
    > Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"
    >       <marjorie_krueger@hp.com>
    >
    > Sent by:  owner-ips@ece.cmu.edu
    >
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  RE: iSCSI: reusing ISID for recovery
    >
    > It would help to get your message thru if you could answer our requests
    for
    > an explanation of your thinking.  We have tried several times to explain
    > our
    > logic (w/examples) but I haven't seen an example from you supporting a
    > scenario in which you see a problem.
    >
    > If an initiator reboots, and has no context information, how can it know
    > whether or not a target has a pre-existing session?  Since there is no
    nice
    > way to know that, I would probably code my initiator to request a login
    > with
    > the X bit set (but as Mallikarjun said, I don't like this overloading of
    > the
    > X bit, it's a special case and makes the coding extra convoluted).  In
    your
    > preferred scenario, this would cause the target to reject the login
    "cause
    > there is no pre-existing session", and the initiator would re-issues the
    > login without the X bit set.  What have you saved anyone from here?
    You've
    > just added latency to the login process.  And either way the initiator
    > codes
    > it's login after reboot, there's a presumably equal probability of
    > encountering this extra exchange.
    >
    > I still haven't seen a plausable example where it does harm to have a
    login
    > w/ ISID=n, TSID=0 close an existing session with this initiator.  I can
    see
    > no case where this would be the wrong decision.  If "this isn't what the
    > initiator intended", this is a defective initiator implementation and
    > closing the other session at least does no harm.
    >
    
     - santoshr.vcf
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:03:50 2001
6315 messages in chronological order