Persistent Reservation Proposal - Group Reservations
Black_David at emc.com
Black_David at emc.com
Thu Jan 3 06:19:22 PST 2008
* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
I'm still checking with our implementers, but my initial reaction
is that Gerry's 2-for-2:
(1) I strongly agree with Gerry's preference for a new RESERVATION
type over a new REGISTRATION type. PR code is already
subtle in a number of ways, and a new reservation type is
much easier to isolate from existing types in specification,
coding, and testing. It should also have better behavior
when mixing implementations that don't all support the
new functionality. We probably need two new types, one
for group write and one for group exclusive.
(2) Is there a reason why we can't use the existing reservation
key as the entity that has to match for the new reservation
type? One would have to ensure that the reservation key
can't be read from the device by PR IN, but we already
have the precedent (and the specification text) to do
that in the All Registrants reservation types. Reuse of
the reservation key is going to be easier to cope with
than inventing a new group identifier.
What initiator implementations are likely to use this new
functionality for what purposes?
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david at emc.com Mobile: +1 (978) 394-7754
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf
> Of Gerry.Houlder at seagate.com
> Sent: Wednesday, January 02, 2008 4:40 PM
> To: t10 at t10.org
> Subject: RE: Persistent Reservation Proposal - Group Reservations
> * 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
> registered (or will register) with a matching GRID get access under
> >3) Don't change PREEMPT, superseding reservations etc. at all - keep
> rules for handling the reservation keys completely orthogonal to the
> >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
> new registration type (existing one without GRID, new one with GRID).
> seems to complicate the rules for making an "all registrants"
> If the initiator making the reservation specifies a GRID, only other
> initiators that registered with that GRID value inherit the
> the others are excluded. This would be a very different result for
> initiators that expect to inherit any reservations just by
> Further, the "unexpectedly excluded" registered initiator will get no
> as to why it doesn't inherit the reservation. if it issues READ
> it gets back a response that says an all registrants reservation is in
> force. The PR generation and reservation key values returned won't
> either, and the GROUP ID value of course will not be returned.
> new reservation type would help here, since the reservation type is
> returned by READ RESERVATION. This might be an advantage of creating a
> reservation type for GRID Registrants Only (or something like that).
> new reservation type would make it more obvious why you didn't inherit
> reservation you expected to inherit.
> Also for backwards compatibility, will initiators be able to register
> existing method (i.e., not specifying a GROUP ID) as well as a new
> that specifies a GROUP ID? The standard will have to describe how
> registrants without a group ID, registrants with a non-matching group
> and registrants with a matching group ID will interact with the
> registrants only reservation and a "GRID registrants only"
> Do we really lose that much if we simply create a "matching
> key" reservation instead? That means only initiators that register
> matching reservation key inherit the reservation. We lose a little bit
> security because the matching ID value is publicly reported and a
> initiator can still join, but a malicous initiator could probably get
> around the Group ID value match just by bute force retries anyway (how
> bytes of group ID is enough?), or just preempt the group ID
> replace it with a regular registrants only reservation. This is a
> method of creating a Group ID reservation that probably works just
> co-operating initiators (as opposed to previously described malicious
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
* 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