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,
    
    In the first place, a multi OS machine should have a different iSCSI name
    for each OS image (that's what the iSCSI Name is supposed to name).  So,
    this sort of collision shouldn't occur.  If these OS's are sharing the same
    SCSI stack or iSCSI stack (and same iSCSI name), then the iSCSI layer
    should be handling this problem directly.  This is one of the reasons why
    "configuring and partitioning of the ISID"s among the components (session
    coordinators) that drive/coordinate/handle/process/instantiate/etc. the
    sessions is an important and desireable feature of these components.  You
    should be able to stuff an iSCSI Name and a set of ISIDs down through the
    layers to the session coordinators (be they hardware or software) so that
    they can independently handle their responsibility without name collisions
    with other components.  The problem you think is going to happen, I think,
    should never happen in a well-behaved system.
    
    So, as I read your model now, you've still got the target "checking to see
    if the session is alive".   I think we're trying to avoid this.  It's not
    so much for optimization (as you alluded to).  For me, its to make the
    target's behavior completely predictable.  Can the initiator judge a priori
    what the target thinks is going on with the other session if it doesn't
    have a context to check on itself?
    
    If the old session is alive enough to answer to NOP, isn't it alive enough
    to clean it up?  When wouldn't it be?
    
    Jim Hafner
    
    
    Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 08/29/2001 12:56:24 pm
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  RE: iSCSI: reusing ISID for recovery
    
    
    
    
    Marjorie,
    
    I probably have some difficulties in explaining and you in reading ... and
    that contributes to increasing distance.
    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.  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.
    
    You will need the X only when the old session is alive (answering to NOP)
    but you don't know how to clean it.
    
    Reboot behavior is close to what you have in the current draft ( a single
    login needed - no X).
    
    The difference is when you have a living connection - then you have for the
    session the same thing as for a connection you have to restart it.
    
    Julo
    
    "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.
    
    Marjorie Krueger
    Networked Storage Architecture
    Networked Storage Solutions Org.
    Hewlett-Packard
    tel: +1 916 785 2656
    fax: +1 916 785 0391
    email: marjorie_krueger@hp.com
    
    > -----Original Message-----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > Sent: Wednesday, August 29, 2001 10:46 AM
    > To: ips@ece.cmu.edu
    > Subject: RE: iSCSI: reusing ISID for recovery
    >
    >
    > Thanks - I started feeling bad. I could not get a message
    > through. Julo
    >
    > "Dev" <deva@stargateip.com> on 29-08-2001 19:03:40
    >
    > Please respond to <deva@stargateip.com>
    >
    > To:   Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
    > cc:
    > Subject:  RE: iSCSI: reusing ISID for recovery
    >
    >
    >
    > Julian,
    >
    > >But - as this is bound to bring
    > >many an initiator writer to set always
    > >the bit to "just cover for the case" I propose that the
    > command fails if
    > >the X bit was on but there was no need for it to be on.
    >
    > The only need to set the X-bit (when ISID, TSID=0) could be
    > to forcibly
    > close a pre-existing session, if any in the target right?
    >
    > I agree with this proposal, as this forces the initiator to issue the
    > command
    > with an X-bit only when there is an error (a session already exists).
    > I also like that returning an error when there is no need to
    > set an X-bit,
    > as it discourages the initiators to set the X-bit by default,
    > for opening
    > a session.
    >
    > Thanks
    >
    > Deva
    > Platys Communications.
    >
    >
    
    
    
    
    
    
    


Home

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