Persistent Reservation Proposal - Group Reservations

Roger Cummings roger_cummings at symantec.com
Fri Dec 14 11:10:17 PST 2007


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

Kevin,
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.
Regards,
Roger
________________________________
	From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Kevin D Butt
	Sent: Monday, December 10, 2007 4:18 PM
	To: t10 at t10.org
	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:
	  http://www.t10.org/ftp/t10/document.08/08-024r0.pdf 
	   http://www.t10.org/ftp/t10/document.08/08-025r0.pdf
	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 us.ibm.com
	http://www-03.ibm.com/servers/storage/ 



More information about the T10 mailing list