Third party persistent reservations source I_T nexus function of XCopy

Knight, Frederick Frederick.Knight at netapp.com
Wed May 1 11:10:28 PDT 2013


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1305014_f.htm">HTML-formatted message</a>

Ø  The REGISTER function allows the copy manager to join a shared reservation
if one already exists (e.g., already created by the application client), but
ignores how this would be cleaned up.
This is what I always assumed, the application client created the initial
state of the reservation in the CSCD.  Then, the copy manager was directed
via the XCOPY to join that reservation.  The cleanup is done by the
application client (PREEMPT of the copy manager).  The application client
could learn what it doesn't already know via a PR-IN (READ KEYS or READ FULL
STATUS).
If it is a tape device, then the application client and the copy manager
"move" the exclusive access reservation back and forth between themselves. 
Yes, I agree that isn't very helpful for shared device like a disk.
Ø  The CSCD descriptors do provide a RELATIVE INITIATOR PORT IDENTIFIER
field, but that does not provide the application client the knowledge of what
the TransportID of the initiator port is.
The SCSI Ports VPD page (88h) (when directed to the REPORT LUNS well-known
logical unit) provides the transportID of all ports in the target device
(both target ports and initiator ports) and the respective mappings between a
relative port ID and its transportID.
		Fred
From: Kevin D Butt [mailto:kdbutt at us.ibm.com]
Sent: Wednesday, May 01, 2013 12:08 PM
To: Knight, Frederick
Cc: owner-t10 at t10.org; Ralph Weber; T10 Reflector
Subject: RE: Third party persistent reservations source I_T nexus function of
XCopy
Fred,
I think we are assuming pretty much the same model you described.  There is
an application client who is the controlling entity.  It does whatever it
wants to do with the CSCD.  It then tells the copy manager to do whatever it
is the application client wants the copy manager to do.  The application
client is the one with the onus to control how the copy manager uses
reservations (this seems apparent since we have some descriptors for
registration and register and move defined).  This seems like the
"cooperative use" you describe.  Figure 17 in SPC-4r36e shows that the copy
manager may be in a logical unit, in a SCSI target, or as a stand alone
device.
If you take one of the scenarios where the copy manager is in a different
device than the application client, then everything I discussed below is an
issue.	There is no way for the application client to have the information
necessary to "move" the reservation to the copy manager.  It can tell the
copy manager to move the reservation back to the application client, but that
is of no worth if there is no way for the reservation to get moved to the
copy manager - or to get established in the copy manager.  The CSCD
descriptors do provide a RELATIVE INITIATOR PORT IDENTIFIER field, but that
does not provide the application client the knowledge of what the TransportID
of the initiator port is.
Note that the registration model only allows the exclusive access type of
reservations to be moved with a REGISTER AND MOVE service action.  This is
where the exclusive reservation I spoke of comes from.
The REGISTER function allows the copy manager to join a shared reservation if
one already exists (e.g., already created by the application client), but
ignores how this would be cleaned up.
How can the copy manager have a reservation with which to use the REGISTER
AND MOVE required in the Third party persistent reservations source I_T nexus
function (DESCRIPTOR TYPE CODE 15h)?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
From:	     "Knight, Frederick"
<Frederick.Knight at netapp.com>
To:	   Kevin D Butt/Tucson/IBM at IBMUS, Ralph Weber
<roweber at ieee.org>,
Cc:	   "owner-t10 at t10.org<mailto:owner-t10 at t10.org>"
<owner-t10 at t10.org<mailto:owner-t10 at t10.org>>, T10 Reflector
<t10 at t10.org<mailto:t10 at t10.org>>
Date:	     05/01/2013 06:50 AM
Subject:	RE: Third party persistent reservations source I_T nexus
function of XCopy
________________________________
It sounds like you are assuming a model where the application client and the
copy manager are independently accessing the CSCD.  I believe the model
assumes that the application client and the copy manager are engaged in
cooperative use of the device.
The application client establishes the reservation (and may write some data).
 Then the XCOPY command is used to have the copy manager write a bunch of
data (this involves the "move" operation).  When complete, the application
client again takes control (and again may write some data).  Maybe the
application client is writing headers and trailers, but the copy manager is
the one writing the data stream in the middle.
I don't believe the model was designed for a copy manager to have exclusive
access (e.g. an independent reservation) without cooperation with the
application client.
		Fred
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Kevin D Butt
Sent: Tuesday, April 30, 2013 12:19 PM
To: Ralph Weber
Cc: owner-t10 at t10.org; T10 Reflector
Subject: Re: Third party persistent reservations source I_T nexus function of
XCopy
Thanks Ralph!
I have more questions for all.
My engineer came back to me claiming that there are issues with the entire
reservation model of extended copy.
The Register function described in 6.4.6.17 Register persistent reservation
key function (DESCRIPTOR TYPE CODE 14h) is available for the application
client to tell the copy manager to register with the CSCD but there is no
function to tell the copy manager to reserve the CSCD.	Therefore, the only
use for the existing register function (14h) is to join an existing All
Registrants or Registrants Only reservation that already exists on the CSCD. 
Furthermore, there is no explicitly stated method for leaving that
reservation or unregistering.  One might be tempted to send an additional
register function (14h) with a zero key as the last segment descriptor but
that would not work should a failure occur in a prior segment.	Then you
would be back to the original issue of having a registration hanging around
with no way to remove it (without PREEMPT or CLEAR).
The other reservation function is 6.4.6.18 Third party persistent
reservations source I_T nexus function (DESCRIPTOR TYPE CODE 15h) which is
only valid for the exclusive access type reservations.	Part of the
description of this function restricts it to tape devices and does not allow
disk devices.  This seems to be overly restrictive.  The other issue is how
the copy manager gets this reservation in the first place.  The only way
would seem to have the application client perform a REGISTER AND MOVE on the
CSCD to the copy manager.  However, this requires the application client to
know the relative target port of the CSCD and the initiator port that the
copy manager will be using.  The application client does not know this
information and so there seems to be no way for the copy manager to ever have
a reservation with the CSCD.
Are we missing something, or is the reservation model for extended copy truly
incomplete?
It seems that at a minimum there should be a new function to reserve the CSCD
and a way to release the CSCD once the copy manager is done with it.  The
release could be a new bit in the existing register function that indicates
that the copy manager shall attempt to release the CSCD after all segments
have been processed - similar to the instructions to do the Third party
persistent reservations source I_T nexus function (15h) after all segments
have been processed.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
Data Protection & Retention
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/
From:	     Ralph Weber <roweber at ieee.org>
To:	   T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>,
Date:	     04/29/2013 07:08 PM
Subject:	Re: Third party persistent reservations source I_T nexus
function of XCopy
Sent by:	owner-t10 at t10.org<mailto:owner-t10 at t10.org>
________________________________
* From the T10 Reflector (t10 at t10.org<mailto:t10 at t10.org>), posted by:
* Ralph Weber <roweber at ieee.org>
*
I believe the "intent" mentioned in question 1 matches the rather
lengthy description that follows the question (up to, but not including,
question 2).
I believe that any errors encountered during the processing of a Third
party persistent reservations source I_T nexus segment descriptor should
not overwrite an error that has already been encountered prior to the
processing of the descriptor. There are other ways to determine the
state of the persistent reservation, but there are few, if any, ways to
determine the nature of the first error.
This makes the answers to questions 2 and 3 be the following:
Question 2: The COMMAND-SPECIFIC INFORMATION field shall not be altered.
Question 3: The COMMAND-SPECIFIC INFORMATION field shall set to the
relative position of the first segment descriptor that detected an error.
All the best,
.Ralph
On 4/26/2013 5:43 PM, Kevin D Butt wrote:
> One of my engineers asked me about a function in extended copy that is
> confusing him.  It confuses me too and I would like to know what the
> expected behavior is.
>
> SPC-4 states:
> <<
> 6.4.6.18 Third party persistent reservations source I_T nexus function
>
> The segment descriptor format shown in table 165 instructs the copy
> manager to send a PERSISTENT RESERVATION OUT command with REGISTER AND
> MOVE service action (see 5.13.8) with the specified I_T nexus after
> all other segment descriptors have been processed. If an error is
> detected any time after receiving a third party persistent source
> reservation I_T nexus segment descriptor, the PERSISTENT RESERVATION
> OUT command REGISTER AND MOVE service action shall be processed before
> the copy operation (see 5.17.4.3) originated by the EXTENDED COPY
> command is completed.
>
> This segment descriptor should be placed at or near the beginning of
> the list of segment descriptors to assure the copy manager processes
> the PERSISTENT RESERVATION OUT command with REGISTER AND MOVE service
> action in the event of an error that terminates the processing of
> segment descriptors. If an error is detected in a segment descriptor
> and third party persistent reservations source I_T nexus segment
> descriptor has not been processed, the copy manager shall not send a
> PERSISTENT RESERVATION OUT command with REGISTER AND MOVE service action.
>
> Placing more than one source third party persistent reservations
> source I_T nexus segment descriptor in the list of descriptors is not
> an error. All source third party persistent reservations source I_T
> nexus segment descriptors known to the copy manager shall be processed
> after all other segment descriptors have been processed.
> >>
>
> This appears to say that this function requires a REGISTER AND MOVE to
> be process after all other segments have been processed, presumably to
> transfer the reservation after all the copy functions have been
> processed.  This segment should be early in the list so it can be
> processed to transfer the reservation even if there is a failure while
> attempting to process any of the segments that occur in the list after
> this function.  And, there is a requirement to process this segment
> even if there is a failure in one of the other segments.  However, if
> the failure occurs in one of the segments prior to this function, then
> the REGISTER AND MOVE shall not be processed.  Further, there are
> allowed to be multiple instances of this function and all instances
> are processed after all the other segments have been processed.
>  Presumably, these functions would be processed in the order they
> appear in the list.
>
> This seems to be the behavior described, but it is difficult to be
> sure this is the intent.
> *Question 1: *Is this the intent?
>
> Assuming this is the correct behavior, then assume a parameter list
> with 10 segments.  There is a Third party persistent reservations
> source I_T nexus function in the third segment descriptor and another
> that is in the sixth segment descriptor.  Further, assume that there
> is an error in processing the eighth segment descriptor.
>
> In 5.17.7.4 EXTENDED COPY command errors detected during processing of
> segment descriptors it states:
> After an exception condition is detected during segment descriptor
> processing:
> b) the copy manager shall indicate the segment that was being
> processed at the time of the exception by writing the segment number
> to the third and fourth bytes of the COMMAND-SPECIFIC INFORMATION
> field. The segment number is based on the relative position of the
> segment descriptor in the parameter list (see 5.17.7.1)
> In this case the segment number put in the third and fourth bytes of
> the COMMAND-SPECIFIC INFORMATION field is 7 (i.e., the eighth
> descriptor).
>
> *Question 2: *What should be put into the COMMAND-SPECIFIC INFORMATION
> field if there is also a failure in processing the REGISTER AND MOVE
> in the third or sixth segment descriptor that is required to be
> processed at the end after all other segments have been processed or
> after an error occurs?
>
> *Question 3:*  What should be put into the COMMAND-SPECIFIC
> INFORMATION field if all copy segments complete without error, but
> then during the REGISTER AND MOVE one of the third or sixth segment
> has an error?  If we indicate the failing Third party persistent
> reservations source I_T nexus function then we lose the fact that all
> the other segments completed successfully.
>
> Thanks,
>
> Kevin D. Butt
> SCSI & Fibre Channel Architect, Tape Firmware
> Data Protection & Retention
> MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
> Tel: 520-799-5280
> Fax: 520-799-2723 (T/L:321)
> Email address: kdbutt at us.ibm.com
> http://www-03.ibm.com/servers/storage/
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to
majordomo at t10.org<mailto:majordomo at t10.org>



More information about the T10 mailing list