RE: iSCSI: reusing ISID for recovery

["Mallikarjun C." <cbm@rose.hp.com>]

Jim,

I am glad you're leaning towards A.  I believe that's the only
option that makes most sense.

>if there is one connection and the
>host looses it, what does it do now for recovery?)

Here's an excerpt from my first email with this subject heading -

---->
   1 If login is sent with the same ISID, same TSID, same CID and X-bit,
     then it means a failed connection is being re-instated (whether
     or not there are multiple connections in the session).  This login
     attempt must be done before the connection timeout (transition M1),
     or if this is the only connection in the session, also before the
     session timeout (transition N6) - to be counted as a connection
     reinstatement effort.
<----

There are two sub-cases under one-connection-per-session targets -
   case-a: Target supports connection reinstatement for the same CID
           (ie. within-session recovery supported).
   case-b: Target doesn't support connection replacement, mandatory
           session recovery is the only supported form of recovery.

The above excerpt from my first email only addresses case-a (it is 
defined in the rev07 draft).

As I said in my last posting (can't quote a URL since the mail
archive appears broken), I was attempting to find a decent solution
for case-b (not to mention the rebooting-host-after-a-crash scenario), 
and I believe option A is the best for it (though option A can be 
used whenever one/all connections reach the RECOVERY_START state on 
the initiator, or initiator doesn't have an active session at all).

Regards.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


>Marj,
>
>All of your questions point out the lack of completeness in my thinking
>(which is why I said "I think this gives...").
>
>I guess I was thinking that the initiator could act like it wants to join a
>new connection to the existing session, so that it can logout that session.
>You're right that this is a problem for 1-connection-per-session targets,
>but don't we have that problem anyway (if there is one connection and the
>host looses it, what does it do now for recovery?)
>
>As I said, I'm starting to lean a bit more toward A.  It's the cleanest and
>simplest.
>
>Jim Hafner
>
>
>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>@ece.cmu.edu
>on 08/27/2001 03:46:23 pm
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI: reusing ISID for recovery
>
>
>
>How would the initiator log out the "dead" session?  Even if it knows a
>TSID, it doesn't have any state, or any connections (assuming reboot).  Are
>you suggesting the initiator perform some new sort of recovery where it
>rebuilds a partial session state and "acts" like it wants to join the dead
>session, for the purpose of logging it out?   Presumeably, this wouldn't
>work with target implementations that only allow one connection? (see
>Mallikarjun's last email) In my mind, any sort of recovery only makes sense
>when there is surviving state information on both parties (I & T).  Is your
>thinking different?
>
>IMO, if option B were provided, initiator implementations would always just
>turn on the "logout" bit, "just to be safe" and therefore, it would
>effectively be no different than option A (just more protocol bits).
>
>Marj
>
>> -----Original Message-----
>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
>> Sent: Monday, August 27, 2001 2:19 PM
>> To: ips@ece.cmu.edu
>> Subject: RE: iSCSI: reusing ISID for recovery
>>
>>
>>
>> Marj,
>>
>> I agree (that is, I don't like option C).  I'm waffling
>> between A and B.  A
>> is simpler and B is "more polite".
>>
>> But I have a twist on option B that may make it a bit more palettable.
>>
>> The problem with option B is that requires extra protocol to have the
>> additional bit to force the logout of the "dead" session,
>> mostly because
>> the initiator doesn't have the context left for the old
>> session.  Suppose
>> we have the target reject but in the response it puts what it
>> is using for
>> TSID in the usual place.  In effect, this is saying to the
>> initiator "I
>> already have a session in place with this ISID/TSID value".
>>
>> I think this gives the initiator the handle it needs to expressly do a
>> logout of the old session (with a valid ISID/TSID pair) or at
>> least enough
>> information for the initiator to figure out what's gone
>> wrong.  That is, it
>> can do session recovery or whatever else is needed.  In this
>> way, we don't
>> need anything like a "force" bit in the login.  He has more
>> steps to do,
>> but they would be the same steps he would do if he just
>> wanted to cleanup a
>> old session he did know about.
>>
>> Jim Hafner
>>
>>
>
>
>
>
>