VERITAS Comments on 03-337r0 for tomorrow's concall

Roger Cummings roger.cummings at veritas.com
Mon Oct 13 13:29:58 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. Its an elegant scheme and does a lot of what VERITAS wanted out of
the Move function, but it assumes a piece of information that our apps don't
normally have - see 1) below.

Funnily enough, our first approach to this problem was also to use Register
- but in that case 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'm told 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 is 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) What happens if the copy manager has registered itself for some reason
before the register with "give" is issued? Does the new registration just
overwrite the previous one?

6) 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.


7) 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.


8) 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.!!


Bottom line is that this approach would work for us IF it's accompanied by
another proposal for how our apps can gain knowledge of the copy manager's
initiator ports and transport IDs. Without that, I think we have a
preference for the Move service action approach along with letting the Copy
Manager register itself. However I don't think the need for additional
information from the copy manager is sufficient justification by itself for
going forward with the MSC project!

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