Persistent Reservation Proposal - Group Reservations

Gerry.Houlder at seagate.com Gerry.Houlder at seagate.com
Wed Jan 2 13:39:31 PST 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
So this is Roger's preference:
>1) Define a new type of REGISTER that contains one (or more) GRIDs;
>2) Extend RESERVE to include a single GRID, and only Initiators that have
registered (or will register) with a matching GRID get access under the
reservation;
>3) Don't change PREEMPT, superseding reservations etc. at all - keep the
rules for handling the reservation keys completely orthogonal to the GRID;
>4) Don't allow GRIDs to be accessed via PR In.
If we don't add a new reservation type, it sounds like you are describing a
new registration type (existing one without GRID, new one with GRID). This
seems to complicate the rules for making an "all registrants" reservation.
If the initiator making the reservation specifies a GRID, only other
initiators that registered with that GRID value inherit the reservation and
the others are excluded. This would be a very different result for current
initiators that expect to inherit any reservations just by registering.
Further, the "unexpectedly excluded" registered initiator will get no clue
as to why it doesn't inherit the reservation. if it issues READ RESERVATION
it gets back a response that says an all registrants reservation is in
force. The PR generation and reservation key values returned won't help any
either, and the GROUP ID value of course will not be returned. Creating a
new reservation type would help here, since the reservation type is
returned by READ RESERVATION. This might be an advantage of creating a new
reservation type for GRID Registrants Only (or something like that). The
new reservation type would make it more obvious why you didn't inherit a
reservation you expected to inherit.
Also for backwards compatibility, will initiators be able to register with
existing method (i.e., not specifying a GROUP ID) as well as a new method
that specifies a GROUP ID? The standard will have to describe how
registrants without a group ID, registrants with a non-matching group ID,
and registrants with a matching group ID will interact with the current
registrants only reservation and a "GRID registrants only" reservation.
Do we really lose that much if we simply create a "matching reservation
key" reservation instead? That means only initiators that register with a
matching reservation key inherit the reservation. We lose a little bit of
security because the matching ID value is publicly reported and a malicious
initiator can still join, but a malicous initiator could probably get
around the Group ID value match just by bute force retries anyway (how many
bytes of group ID is enough?), or just preempt the group ID reservation and
replace it with a regular registrants only reservation. This is a simpler
method of creating a Group ID reservation that probably works just fine for
co-operating initiators (as opposed to previously described malicious
ones).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list