Third party persistent reservations source I_T nexus function of XCopy

Ralph Weber roweber at ieee.org
Mon Apr 29 18:40:47 PDT 2013


* From the T10 Reflector (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



More information about the T10 mailing list