Persistent Reservation Proposal - Group Reservations

Kevin D Butt kdbutt at
Mon Dec 17 06:51:24 PST 2007

Formatted message: <A HREF="r0712170_f.htm">HTML-formatted message</A>

Thank you for your feedback.  I am certainly willing to entertain  other 
methods for accomplishing the end goal in an easier fashion.  I am not 
sure I understand how your proposed method makes it more backward 
compatible.  In my proposal PRin would show a different type of 
reservation and hence the application clients would not try to join the 
reservation because they don't know about the type.  In your proposal, 
application clients would not be allowed to register.  This is a deviation 
|from what they can always do today - unless there is a resource issue. 
This seems more disruptive to me.  I would assume that there would be a 
new additional sense code added for UNABLE TO REGISTER BECAUSE A GROUP 
RESERVATION IS IN PLACE (or analogous).  This would be a new thing for 
failure to register and there would be pain at the register point. Perhaps 
that is better than at the reserve point - but I would think that it would 
be better handled as a reservation conflict since that is what it is 
instead of something the application client does not understand.
As for "all registrants" type vs. "registrants only" I didn't see where 
the difference would be interesting, but I am not opposed to providing a 
way to switch between which of these two types is done.  Whether it is 
additional types or some bit during registration etc.
As for some of the corner cases mentioned below, if each I_T nexus that is 
supposed to be part of the group reservation is required to be registered 
before the reservation is made, and if the reservation is released when 
the last group reservation participant is unregistered, then I think we 
don't have an issue.
I would prefer that we work together to shape a mutually beneficial 
proposal as opposed to have "competing" proposals.  I am willing to modify 
my proposal where it can be made easier and such.  I am not sold that my 
proposed method is the only way or even the best - it's just the way I 
thought of doing it.  I admit that I have always been very confused about 
the usefulness of RA and AR types.  They make absolutely no sense in the 
tape world.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at 
"Roger Cummings" <roger_cummings at> 
Sent by: owner-t10 at
12/14/2007 12:10 PM
Kevin D Butt/Tucson/IBM at IBMUS
<t10 at>
RE: Persistent Reservation Proposal - Group Reservations
First of all, let me say that I completely support what you're trying to 
do here. I think that providing a method in persistent reservations (PRs) 
to support shared access between ONLY a specifically-designated set of 
systems is a worthy goal, and something we should do in SPC-4.
Adding a set of Transport IDs to Reserve as per your document 08-024 & 
08-025 is certainly possible, but it's a massive change to the way that 
PRs work today, and it throws up a bunch of nasty corner cases and 
backwards compatibility issues.
The massive change comes from the fact that now the Target will have to 
remember which registrations are in the Reservation, and which are not. It 
will probably have to preserve all of the transport information for the 
life of the reservation.
The corner cases are things like, what happens if there's no longer a 
registration that corresponds to the transport ID in the Reserve? Does the 
Reserve succeed? What happens if a registration comes in later, after the 
reservation has been established - does that device it get access?
Backwards compatibility issues may arise like this: An existing device 
registers, and finds it has no access, so it does a PR In and finds out 
that a reservation is in place, retries its access and still it has no 
access. What does it do next, preempt the reservation because it assumes 
the Target is broken?
Reserve also has to be an "atomic" command, and I've always thought that 
was why it's functionality is as compact as it is today. Most of the 
complex operations related to addresses and keys are done at registration 
time, and those operations don't have to be atomic.
One more thing: you chose for your new "group" reservations to follow the 
"all registrants" approach is terms of the definition of the reservation 
holder. While that's fine by me (obviously), I suspect there are also 
situations where group reservations that follow the "registrants only" 
approach might be useful.
The bottom line from my point of view is this: Your proposal is feasible 
and we can probably make it work. But I wonder if there's an easier way to 
achieve the same goal that is more compatible with existing practice and 
requires less of a change in functionality on the Target side.
What if we didn't add any new reservations types, but instead added some 
new functionality to the registration process? What I'm thinking of a new 
Register feature that causes the Target to kill all existing 
registrations, create the registrations identified in the transport IDs in 
the Register command, and not accept any future registrations. That way, 
we don't need any changes to Reserve, and an Initiator with existing 
functionality would just not be able to register and therefore would not 
be confused.
Does that make sense to you? Is there a chance this is an easier approach? 
If so, I'll write up a detailed proposal that's the equivalent of 08-025r0 
and we can compare and contrast at the next CAP.
Again, thanks for getting this started, I think it's a worthwhile endeavor 
and I'll be glad to put some cycles towards defining this sort of 
functionality for SPC-4.
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Kevin D 
Sent: Monday, December 10, 2007 4:18 PM
To: t10 at
Subject: Persistent Reservation Proposal - Group Reservations
I have posted two documents related to an additional Persistent 
Reservation Type.  The first document is a presentation on where 
persistent reservations are today and where they fall short in the 
scenarios covered by the proposal.  It also covers the intent of the 
proposal and what will be proposed.  The second is the actual proposal 
Your PDF file will be posted at:
Normally, the posting/archiving process takes about 30 minutes. 
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware, IBM
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at 

More information about the T10 mailing list