(Resend) FW: 99-230r0 - Extended Copy Support for Persistent Reservations

Coughlan, Tom Tom.Coughlan at COMPAQ.com
Tue Sep 14 08:30:31 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* "Coughlan, Tom" <Tom.Coughlan at compaq.com>
*
I didn't see this reflected, so here it is again.

-----Original Message-----
From: Coughlan, Tom 
Sent: Monday, September 13, 1999 3:32 PM
To: 'Gerry_Houlder at notes.seagate.com'; t10 at t10.org
Cc: 'Ralph Weber'
Subject: RE: 99-230r0 - Extended Copy Support for Persistent
Reservations


>(2) Tell the copy manager the key value used by the original initiator. If
>the copy manager registers with this key, it could "inherit" even an
>exclusive registration.

No, an initiator does not inherit another initiator's exclusive registration
by registering with the same key.  Reservations are enforced exclusively by
the initiator identifier, not the key.  The key value only influences the
behavior of PR Out commands.  The only thing you get if you register with
the same key as another initiator is you get preempted as a group.  (A cool
trick for preempting all the initiators on the same host system with just
one command.)

The proposal does not provide a method for doing any persistent reservation
environment other than a registrants only environment.  If someone thinks
this is a problem they should speak up.  If anyone thinks this might be a
problem in the future, then it would be a good idea to craft the proposal to
allow future expansion.

Tom Coughlan
OpenVMS SCSI & FC Project Leader
Compaq Computer Corporation
110 Spit Brook Rd. ZKO3-4/U14
Nashua, New Hampshire 03062-2698
Phone:	603-884-0933 
Fax.:		603-884-0189
Mail: 	tom.coughlan at compaq.com


-----Original Message-----
From: Gerry_Houlder at notes.seagate.com
[mailto:Gerry_Houlder at notes.seagate.com]
Sent: Friday, September 10, 1999 10:17 AM
To: t10 at t10.org
Subject: RE: 99-230r0 - Extended Copy Support for Persistent
Reservations


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry_Houlder at notes.seagate.com
*
I would think the extended copy manager wants to use the "shared key"
concept to "inherit" the needed reservation permissions so it could do the
required copy operations. This used to be accomplished via the 3rd party
reservation (were the original initiator explicitly made the needed
reservations before telling the copy manager to do its work).

There are two ways the original initiator can share its persistent
reservation with a copy manager:
(1) Use a registrants only reservation type so that all registrants
(regardless of key value) can inherit the reservations. This might not be
desired if there are other registered initiators that shouldn't get access
permission, especially while a copy operation is in process.
(2) Tell the copy manager the key value used by the original initiator. If
the copy manager registers with this key, it could "inherit" even an
exclusive registration.

I didn't see a way (by having the key value in the copy descriptor, for
example) for method 2 to be accomplished. I suppose there could be "outside
of SCSI" methods to communicate this, but that would make it less likely
that this method would ever be used. Have I missed something, or is method
2 not planned as a normal method for extended copy?





"Coughlan, Tom" <Tom.Coughlan at COMPAQ.com> on 09/09/99 04:04:49 PM

To:   "'roweber at acm.org'" <roweber at acm.org>, "'T10, Reflector'"
      <T10 at t10.org>
cc:    (bcc: Gerry Houlder)

Subject:  RE: 99-230r0 - Extended Copy Support for Persistent Reservations




* From the T10 Reflector (t10 at t10.org), posted by:
* "Coughlan, Tom" <Tom.Coughlan at compaq.com>
*
Ralph,

As you may have guessed, I am a bit concerned about the fact that this
proposal provides support for the "Register" service action, and not the
"Register and Ignore Existing Key" service action.  Here is why:

Normally, if an initiator attempts to register a key with a target, and
discovers that for some reason there is already a key registered in the
target for this initiator, that initiator has the tools it needs to
recover.
The process is painful, but effective: the initiator has to do a Read Keys
action, and then attempt to register with the "existing key field" set to
each key in the list until it succeeds.

The best example of when this situation might arise is when the operating
system on a host is abruptly shutdown, leaving reservation state in the
devices, and another operating system type is booted on the same initiator
hardware.

The Extended Copy function presents us with a new environment, where the
initiator may not be able to access the copy target directly, but only
through the copy manager.  The proposal says that the only service action
the initiator can execute through the copy manager is a Register.  What if
the Register fails because there is already a key in the copy target for
the
copy manager, but the initiator does not know the key value?  There is no
way for the initiator to get the copy manager registered with a key value
that the initiator knows.

I said that I am only a bit concerned about this, because it can be argued
that the only reason an initiator needs to know the key of the copy
manager,
is so that the initiator can Preempt and Abort the copy manager's access to
the copy target.  The initiator can only do this if it can access the copy
target directly, which violates the initial assumption.

Still, I'm not sure I have considered all the possible cases, and I am sure
that dealing with an Extended Copy register function that sometimes can't
be
made to work will add complexity to the overall system.  The "Register and
Ignore Existing Key" action provides the needed functionality with less
complexity than "Register", or little additional, if you decide to support
both.  Therefore, I would recommend that the proposal be modified to allow
the "Register and Ignore Existing Key" service action, either exclusively,
or in addition to the "Register" service action.


Tom Coughlan
OpenVMS SCSI & FC Project Leader
Compaq Computer Corporation
110 Spit Brook Rd. ZKO3-4/U14
Nashua, New Hampshire 03062-2698
Phone:    603-884-0933
Fax.:           603-884-0189
Mail:     tom.coughlan at compaq.com



-----Original Message-----
From: Ralph Weber [mailto:ralphoweber at compuserve.com]
Sent: Saturday, August 21, 1999 9:09 AM
To: T10, Reflector
Subject: 99-230r0 - Extended Copy Support for Persistent Reservations


* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
*
A proposal for consideration at the September meetings has
been placed on the T10 FTP site as:

< ftp://ftp.t10.org/t10/document.99/99-230r0.pdf >

The complete proposal appears only in the PDF file.  An
overview of the proposal is as follows:

Doc:  T10/99-230r0
Date: 15 August 1999
To:   T10 Technical Committee
From: Ralph Weber, LSI Logic Alternate Member of T10
Subj: Extended Copy Support for Persistent Reservations


Third-party reservations were invented to support the COPY command.
So, what's being done to match the new reservations paradigm to
EXTENDED COPY?  This proposal attempts to address that question.

Unlike RESERVE/RELEASE, persistent reservations are designed to
support concurrent sharing of a device by multiple initiators.  Thus,
persistent reservations need no additions to support EXTENDED COPY.
However, an addition is required in the EXTENDED COPY command
definition.

The complete document in the PDF file proposes the definition of a
new EXTENDED COPY Segment Descriptor that instructs the copy manager
to register a specified reservation key with a specified copy target
device.  Note: the copy manager is not instructed to make or preempt
a persistent reservation, only to register a key.  By using a
Registrants Only reservations and preempting previous registrations
by the copy manager, the initiator can create an environment where
registering a reservations key is the only action a copy manager need
take.




*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org






More information about the T10 mailing list