Persistent Reservation Proposal - Group Reservations

Raymond Gilson raymond_gilson at symantec.com
Thu Jan 3 10:24:11 PST 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Raymond Gilson" <raymond_gilson at symantec.com>
*
The problem with a new type is that you will need FOUR new types (5 - 8
are current shared access types of different flavors).	We have seven
available types left, so using four of them seems to be a bad idea (if
it can be avoided).
What if we added a bit to the "report capabilities", and "read
reservation" pages to report the support for or existence of the GRID
reservation.  Add a bit to the "PERSISENT RESERVE OUT" CDB to indicate
that the parameter list will fill in the GRID field.  The GRID will be
valid on a RESERVE service action and on a new "Join" service action.
Perhaps we can reclaim some of the currently "Obsolete" fields in the
parameter list for the GRID field?
An initiator would register, and reserve the device with the new GRID
field and CDB bit.  Other initiators can come along and read that the
reservation is a shared type but with GRID control.  They can then issue
the "Join" service action with the GRID field filled in.  If the correct
GRID value is sent, the target will accept the command, and allow the
new initiator to join the shared reservation.  If the GRID value is
incorrect, the target will fail the command.
Hopefully, the remainder of the functionality (preempt/abort etc) will
remain intact (and they must remain intact).
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight,
Frederick
Sent: Thursday, January 03, 2008 10:34 AM
To: Black_David at emc.com; Gerry.Houlder at seagate.com; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I'm still mulling over some of these discussions, but absolutely agree
with #1 - a new reservation type is preferred.
As for #2, I disagree.	How would I remove a single initiators
registration (preempt a single initiator from the group) if they all
must have the same KEY to join the group?
More comments later.
	Fred Knight
-----Original Message-----
From: Black_David at emc.com [mailto:Black_David at emc.com]
Sent: Thursday, January 03, 2008 9:19 AM
To: Gerry.Houlder at seagate.com; t10 at t10.org
Subject: RE: Persistent Reservation Proposal - Group Reservations
* 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?
Thanks,
--David
----------------------------------------------------
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
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
> 
> 
*
* 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
*
* 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