iSCSI: handling of persistent reserves during initiator reboot

["Thomas McSweeney" <rf42tpme@us.ibm.com>]

I'd like to move this discussion from the iSCSI MIB exploder to the IPS
exploder, since it has implications on the iSCSI spec.

John Hufferd appended a question asking whether the target would reset its
session counters under the following conditions:

>And if the Host was rebooted but comes back to the Target
>with the same iSCSI name and ISID, of a broken connection --
>which has outstanding persistent reserves -- then the
>Target must respond with the corresponding TSID of the
>interrupted Session.   This means that the Session has
>continued, and the connection has also been continued.

My response was:

I disagree.  Certainly, it is a new connection, so at the target the old
connection object would disappear and be replaced.  I think it is a new
session also - spec section 1.2.3 states that Login with a null TSID is for
a new session.  Whether or not the old session is cleaned up is still a
matter of debate...  Section 6.7.3 mentions "Login with an implied Logout",
which seems to apply to this case.  However, that depends on how the
"multiple sessions between one initiator and one target" issue is resolved.

If the initiator retained enough info about the I-T nexus despite the
reboot to send the correct non-null TSID on the (re)Login, then it should
have saved all its counters too.  The target does not reset its session
object counters due to within-session connection recovery.

John replied:

>I did not say that the initiators saved the TSID, just their own ISID. The
>point is that it is a SAM-2 requirement that if Persistent Reserves are
>outstanding, the Initiator should be able to clean them up or continue to
>work with them after a boot.  This will mean that the target will have to
>detect that  Persistent Reserves are outstanding, and keep approprate
>information around for the reconnection (with the InitiatorName=xxxxxxx,
>and ISID of zzzzzzz).  The Target will then need to respond --- when a new
>session is being created for InitiatorName=xxxxxxx, and ISID or zzzzzzzz
>--- with the TSID used with the broken connection.  In this way the
>initiator can clean up or continuation of the Persistent Reserves.

>Persistent Reserves are a bit different then any other State that is kept
>by the Target.

I believe the Login which the rebooted initiator sends has to be for a
"leading connection", so it can learn the value of negotiated iSCSI
parameters like MaxConnections and FMarker that are only exchanged during
initial session activation.  So to me it's a new session.  It shouldn't
matter to the underlying SCSI resources whether the TSID matches the
previous session or not.   I'm not sure how the target should handle the
outstanding persistent reserves - I assume they can be moved to the new
session.  Now it's time for the real experts to chime in...

I'd like to see a new section added to Chapter 6 of the spec to describe
the handling of outstanding persistent reserves, since it is a special
recovery case.

As for the SNMP objects, I think the counts will be reset (old session
instance disappears, new session instance initialized to zero).  This would
make the target's counts consistent with the initiator's.  We plan to
discuss the tracking of long-term (across multiple sessions) usage per
initiator in Nashua.

Tom McSweeney
iSCSI Development, Storage Systems Group, IBM
Email: rf42tpme@us.ibm.com
Phone: (USA) 919-254-5634  (tie line: 444-5634)
Fax:   (USA) 919-254-0391  (tie line: 444-0391)