Kevin,
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
point?
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
register.
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
proposal.
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?
Regards,
Roger
Roger,
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.
Thanks,
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@us.ibm.com
http://www-03.ibm.com/servers/storage/
"Roger Cummings"
<roger_cummings@symantec.com>
Sent by: owner-t10@t10.org
12/14/2007 12:10 PM
|
|
To
| Kevin D
Butt/Tucson/IBM@IBMUS
|
|
cc
| <t10@t10.org>
|
|
Subject
| RE: Persistent Reservation
Proposal - Group Reservations |
|
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@t10.org
[mailto:owner-t10@t10.org] On Behalf Of Kevin D Butt
Sent:
Monday, December 10, 2007 4:18 PM
To: t10@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@us.ibm.com
http://www-03.ibm.com/servers/storage/