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
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@us.ibm.com
http://www-03.ibm.com/servers/storage/