Re: iSCSI: handling of persistent reserves during initiator reboot

["Jim Hafner" <hafner@almaden.ibm.com>]

Sandeep,

Suppose an initiator has a persistent reservation for a logical unit on
some target device.  This initiator has two choices:
a) a requirement, as you suggest, to remember some initiator state (the
ISID it used for the particular target device and the reservation key that
it was using, the latter in any case) OR
b) it doesn't recover the reservation "for free" but must use a heavier
hammer (like prempt and abort) to recover the reservation

As in another part of my note, a host rebooting is only one scenario where
this reservation auto-recovery should occur (as seen from the SCSI layers).
For all the other cases, the host doesn't loose any state (it never went
down) so things are OK.

For a host rebooting, a lot has to do with why it shutdown in the first
place and whether it expects to get back its reservations with minimal
effort.   One can argue that in the case of reboot, the host will start
from scratch for everything and use the bigger hammer.  Or one can argue
that if it really cared, it can preserve this state information.  I don't
think this is a major requirement either way.

As for iSCSI-FC bridges, I'm not thought about the requirements.  A very
large lot depends on the model that that bridge implements:
a) how much does the bridge attempt to be a "front" for an FC device and
tunnel initiator state through it
b) how much does the bridge act as an independent iSCSI target and just
aglomerate all (some of) the logical units on the FC network behind it.

For case (b), the bridge is an iSCSI target device and therefore needs to
support all target requirements.
When I look at case (a), I seem to always come to the conclusion that such
bridges cannot be very stateless and that this extra burden is relatively
minimal.  For example, the bridge will need to something non-trivial to
restore initiator state through itself when (a) changes occur on the FC
side, (b) the target resets completely, (c) the IP side resets (sessions
crash and burn for IP or link layer errors).  Adding an ISID to the "saved"
state along with the iSCSI Initiators Name doesn't sound like a whole lot
of extra stuff.

Jim Hafner


Sandeep Joshi <sandeepj@research.bell-labs.com>@research.bell-labs.com on
04-24-2001 09:51:15 AM

Sent by:  sandeepj@research.bell-labs.com


To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: handling of persistent reserves during initiator
      reboot



Jim Hafner wrote:
>
> Tom,
>
> Here's my two cents. Apologies for being long-winded.  In short, I think
I
> agree with most of your sentiment.
>
> 1) In order to accommodate Persistent Reservations (and a few other SCSI
> things), I think it is important to have some mechanism for an initiator
to
> reestablish some nexus state information through logout/login.  The
current
> thinking in N&DT is that the initiator should reuse it's old ISID and the
> target should respond with the old TSID (thereby rebuilding the nexus).
> Note, the initiator starts with TSID=0, as if it was a new session.  The
> target that remembers the old ISID/TSID pair (can reuse the old TSID).
Keep
> in mind that that target is already remembering some state information
(the
> reservation) about the ISID/TSID (and Names) relationship in the nexus,
so
> this isn't a big deal.

If I am not mistaken, isnt this also adding to initiator state ?
Initiators now have to remember the ISIDs used with every target
(or have only one!)

And doesnt this also add state to iSCSI-FC bridges...?

Regards,
-Sandeep