Comments on 03-337r0

Roger Cummings roger.cummings at veritas.com
Mon Oct 13 12:54:26 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* Roger Cummings <roger.cummings at veritas.com>
*
Rob,

Thanks to yourself & Bill Dallas for creating the scheme defined in 03-337r0
- I think it does most of what VERITAS wanted out of the Move function.
Funnily enough, our first approach to this problem as also to use Register -
but to define a third party registration. Frankly, we didn't think of using
the initiator ports feature.

Here's some specific comments on the text that we can discuss tomorrow:

1) The advantage of this approach over the Move service action is that the
Copy Engine doesn't need to register itself. The disadvantage is that the
Backup application needs to know the transport ID of the Initiator port of
the copy manager. I don't believe that there's a good way to obtain this
information from the Copy Manager today, so presumably this has to be a
priori knowledge. I believe that we've started to see Copy Managers with
multiple initiator ports as well, and so there's also a need for some way to
control or determine which port's being used for a specific command.


2) There's nothing to say that only the I_T nexus that Gave the reservation
can take it back again. Was that your intention, or don't you see that
restriction as necessary? I think we'd prefer if the restriction was
included.


3) Is the Given reservation still able to be preempted? If so, then I think
we need to have some more words about which key is reported for the
reservation holder when the reservation is given. The note towards the
bottom of page 11 starts to do this, but needs more details, something like:

NOTE: The I_T nexus that sent the PERSISTENT RESERVE OUT command remains
registered.

If the type of registration is one of the All Registrants types, then the
I_T nexus that performs the Give remains a reservation holder (see 5.6.2.6).


If the type of reservation is one of the Registrants Only types, then the
I_T nexus that performed the Give maintains access, but the Reservation Key
reported for the Reservation is for the I_T nexus that has been "given" the
reservation.

If the type of reservation is one of the Exclusive Access types, then the
I_T nexus that performed the Give loses access, but no United Attention is
generated and the Reservation Key reported for the Reservation is for the
I_T nexus that has been "given" the reservation.


4) Are Unit Attentions created during the Give or Take process? I don't see
any good reason why they should be, but perhaps it should be explicitly
stated that they are NOT.


5) Again at the bottom of page 11, the paragraph:

"If any of the conditions are not true, the GIVE bit shall be set to zero."

is a little confusing. Am I right in thinking that you meant:

"If any of the conditions are not true, the device server shall perform the
actions defined for Register as if the GIVE bit had been set to zero."

???? If so, the note at the end of the Take section seems to be similarly
modified.


6) Does the PR Out Register with Give and Take still increment the value in
PRgeneration? My belief is yes, and thus no additional words are needed.


7) And a final real nit. I agree with the Editors Note in 5.6.2.8 that the
list is FAR to useful to go into SPC-3.!!

Thanks, and talk to you @ 10am Central tomorrow. Again, the call-in details
are:

Dial-in Number 877-468-2136 (toll-free within the US) or 918-583-3261
Participant code 778685





Roger Cummings
VERITAS Software

roger.cummings at veritas.com
*
* 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