Persistent Reservation Proposal - Group Reservations

Roger Cummings roger_cummings at
Tue Dec 18 06:08:50 PST 2007

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

Thanks for your comments in turn. 
I think we actually agree about a lot more in relation to this subject
than we disagree about, so we should be able to work through these
issues and come up with a single proposal that works for both of us - I
certainly don't want two different ways of doing this! But by the same
token I don't want a disk-type group reservation and a tape-type group
reservation either, and that means whatever we come up with has to be
straightforwardly implementable by devices that support the RO & AR PR
types today. 
And this is probably the major concern that I have with your proposal -
I believe it requires a Target to remember which registrations should be
included in the group for a Reservation, and to validate those
registrations within the context of an atomic Reserve operation. Whereas
my proposal prevents devices that are not in the group from registering
in the first place, and thus Reservations work just as they do today -
both the RO and AR types.
That having been said, I do not work for a hardware Target supplier that
supports PR today, so I might not be representing their concerns
adequately. Would anyone else more qualified care to comment on this
With regards to the other points you raised:
a) I'm not sure we can rely on existing devices to check the type of an
existing reservation before registering. Those existing devices may
assume that they get access under ANY non-exclusive PR when they
b) The point that you raise about registrations being denied is right,
but resource issues do happen and I know we do see that and handle that
in some of our code. On the other hand, a host that sees the
Registration being rejected, assumes that PR therefore isn't supported,
and falls back to RESERVE/RELEASE wouldn't be very good! I think we
always now use PR IN to check for PR support, but I'll check that.
c) Yes, I agree that the RO & AR types aren't very interesting or
significant in the tape world, but they are interesting in other uses
and some of those uses could really use the other features of your
d) Re the corner cases, let me ask this question? If a device that has
access under the reservation de-registers, and then registers again,
does it have access? If we can hold the line of definitely not, then I
agree that will be simpler, but I'm not sure that's feasible.
e) I agree about the need for a new ASCQ, and yes there would be pain on
the host side at the register point. But the host has to handle that
action in the resource conflict case today, and handling it there saves
the target a whole lot of work.
f) I don't have an issue with reporting Reservation Conflict when one of
the new Reservations are in place, but you'd only do that under the
existing conflict rules, right? You'd still allow registrations to be
accepted after the Reservation was in place, just that those new
registrations would get access - that what I'm worried about.
And BTW we still have another major issue to discuss. Do you want to
change anything regarding Preempt?
	From: Kevin D Butt [mailto:kdbutt at] 
	Sent: Monday, December 17, 2007 9:51 AM
	To: Roger Cummings
	Cc: t10 at
	Subject: RE: Persistent Reservation Proposal - Group
	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 Butt
	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