16 May 2011

T10/11-059 r8

To: INCITS Technical Committee T10 From: Fred Knight, NetApp Rajeev Nagar, Microsoft Bryan Matthew, Microsoft Daniel Suman, Dell Lazarus Vekiarides, Dell Email: knight@netapp.com rajeevn@microsoft.com brymat@microsoft.com Daniel_Suman@dell.com Lazarus_Vekiarides@dell.com Date: 16 May 2011 Subject: SBC-3/SPC-4 - XCOPY Lite - Tokenized operations 1) Revision history Revision 0 (Jan 10, 2011) Revision 1 (Feb 1, 2011) Incorporate feedback received Revision 2 (Feb 4, 2011) Incorporate changes from Feb 4 con-call Revision 3 (Feb 18, 2011) Incorporate changes from Feb 18 con-call Revision 4 (Mar 2, 2011) Incorporate additional feedback and changes from March 1 con-call Rewrite so PROXY DATA is managed by the copy manager - this eliminates named areas, all SAM changes and use the ROD name from 11-079 Change meaning of requested token lifetime to inactivity timer Fix some typos Make some VPD page length fields 8 bytes (and realign) Revision 5 (Mar 14, 2011) Incorporate feedback from March 9 CAP meeting and the March 15 con-call. Change block device token descriptor to block device range descriptor Put the VPD page data into the descriptor format Revision 6 (Apr 13, 2011) Incorporate feedback from the April 13 con-call. Revision 7 (Apr 27, 2011) Incorporate e-mail feedback. Revision 8 (May 16, 2011) Incorporate feedback from May 11 CAP meeting and stabilize.

2) Related documents sam5r6 - SCSI Architecture Model - 5

Proposal - XCOPY Lite - Tokenized READ/WRITE 1

T10/11-059 r8

16 May 2011

sbc3r26 SCSI Block Commands 3 spc4r29 SCSI Primary Commands - 4 11-078r3 - Basic Extended Copy Upgrades 11-079r4 - Byte Agglomeration Objects 11-080r1 - Byte Agglomeration Tokens 3) Overview Hosts do lots of data movement. They read the data from a device, over the bus, into the host, then write it back out again from the host, over the bus, often back to the same SCSI target device that it came from (different blocks, maybe a different LUN). The data may be shared in a host cluster in such a way that other hosts write the same data back out, again, often to the same SCSI target device. This uses large amounts of bus bandwidth just to send data back to the same port it came from, or to send it back to the same target it came from. This uses host CPU, host memory, bus bandwidth, and a number of other resources. This amount of data movement is far more than actually required to accomplish a simple data movement task within a single SCSI target device. In addition, storage devices (such as arrays) now have intelligent operational capabilities that allow substantial processing to occur directly within the device. Many devices have the ability to make copies of the data for snapshots or clones, or the ability track writes, or de-duplication, or other advanced capabilities. The goal of this proposal is to create an interface to use intelligent device capabilities to simplify data movement, while retaining the existing READ / WRITE model of application operation. This movement may be accomplished in any number of ways (such as taking a snapshot of the data, otherwise saving a point in time copy of the data, tracking if the requested blocks have changed since the request for the point in time copy was made, or any number of other methods). Therefore, new commands are created for a PROXY READ operation to create a representation of the data content (for example, by creating a data content descriptor), and PROXY WRITE operations to use the representation of the data to cause the actual data to be written to the media (for example, write from the area described by the data content descriptor where the copy manager previously placed the data, or from the original - as yet unmodified - media location, or other method). This allows the data to be moved by a READ / WRITE type application without the data ever moving across the bus, using any number of different possible innovative techniques within the storage device. This proposal makes no effort to standardize how the device actual implements the point in time mechanism. Overall, the proxy read/write will be faster, the bus should be left with more bandwidth for doing real work, the host should be left with more memory for doing real work, and the host should be left with more CPU cycles to do real work. Pictorially one implementation (copy/snapshot based) might look something like this:

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

SCSITargetDevice
Named Area 1 (copy) Named Area 2

LUN A

LUNB

PROXY READ

PROXY WRITE

The basic flow of the PROXY READ / PROXY WRITE operations would go something like this:
a) Application wants to read data for a copy: 1) Issue PROXY DATA READ command to LUN A w/transaction id=AA (to load named area 1 from specified LBAs of the media). 2) Issue RECEIVE PROXY RESULTS command w/transaction id=AA (to get the named area token - i.e. the name of named area 1 associated with transaction id=AA). b) Application wants to write the data that was read: 1) Issue PROXY DATA WRITE command to LUN B w/transaction id=BB and w/named area token (from step a2) (to write buffered data to specified LBAs of the media). 2) If error, issue RECEIVE PROXY RESULTS command w/transaction id=BB to get error details.

The named area token is opaque, immutable, and managed by the copy manager. The named area token is not just single use; multiple PROXY WRITE commands (referencing the same named area token) may be issued as long as the named area token remains valid. The validity of the named area token is controlled by the copy manager. The copy manager may delete a named area, reuse a named area (assigning a new named area token), or take other destructive action on a named area at anytime, and as a result, the original named area token becomes invalid. The host must use fallback methods (normal READ / WRITE should a named area token not exist when referenced). In another implementation, the named area token may simply represent the original blocks on the media (in this case, the named area is actually the original blocks). The device server tracks operations that alter those blocks, and if such operation occurs, then the named area token becomes invalid. As long as the blocks remain unaltered, the named area token remains valid, and the blocks can be copied to other locations.
Proposal - XCOPY Lite - Tokenized READ/WRITE 3

T10/11-059 r8

16 May 2011

SCSITargetDevice
Named Area 1 (LBA pointers) Named Area 2

LUN A

LUNB

PROXY READ

PROXY WRITE

The named area token is simply used as a representation of the original data, no matter how that original data is retained by the storage device. Since the named area tokens are uniquely assigned within the SCSI target device, the PROXY DATA READ may be issued to one LUN, while the PROXY DATA WRITE may be issued to a different LUN (as in the example above). In this way, the PROXY DATA commands are modeled

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

as much like standard READ / WRITE commands, so the same application programming model may be used.

PROXY DATA commands are not initially intended to span multiple SCSI target devices; in the future, PROXY DATA commands could be extended in a standardized manner to be able to span multiple SCSI target devices. Those operations could use existing EXTENDED COPY commands or normal READ / WRITE commands. In addition, there is nothing that precludes a vendor specific means from being used to communicate named area token values and transfer data between multiple SCSI target devices. Due to the relationship between the named areas and the SCSI target device, each LUN will be required to have a SCSI target device identifier - to aid the host in knowing which LUNs are within the same target, and therefore share a common named area token name space. The EXTENDED COPY command is extremely complex. This complexity, including the requirements for target descriptors and their knowledge within the application client has helped contribute to slow adoption of XCOPY by the host community. This proposal is intended to build on 11-078 to create a lighter and easier to use subset of the EXTENDED COPY command. Between the ease of use features in 11-078, and the simplified CDBs and operational model in this proposal it is expected that the adoption by hosts will be substantial. As a result some of the language and capabilities from 11-078 have been incorporated into this proposal (such as the ROD token, and the use of EXTENDED COPY service actions).

Proposal - XCOPY Lite - Tokenized READ/WRITE

T10/11-059 r8

16 May 2011

Existing text (including all the new text that was previously reviewed) is shown in BLACK, new text since the last rev (including text not reviewed yet) is shown in GREEN, as is new text to merge into text already in the standard, deleted text is shown in RED, editors notes and authors notes are shown in BLUE. Proposal:

SBC-3 changes:
3.1.x ROD token: a world wide unique value that is associated with a point in time data representation (see 3.1.z). See x.y - aka 11-080 text. 3.1.y token: a representation of a collection of data. See <match definitions used in SAM-5/SPC-4?>. 3.1.z point in time data representation: an ordered set of logical blocks where the user data and protection information, if any, does not change for the duration of the validity of the representation (see SPC-4)(see 4.x).

<...> 3.2 Acronyms

... RAID ROD RBC ... Redundant Array of Independent Disks Representation of Data (see SPC-4) SCSI Reduced Block Commands

<...> 4.x Block Device ROD Token Operations

4.x.1 Block Device ROD Token operation overview Application clients request that block device ROD token operations be performed using the commands summarized in this subclause. Copy managers (see SPC-4) that implement the POPULATE TOKEN command or the WRITE USING TOKEN command shall implement the items in this list: a) b) c) d) POPULATE TOKEN command (see 5.a); WRITE USING TOKEN (see 5.b) command ; RECEIVE ROD TOKEN INFORMATION command (see 5.c and SPC-4); and Third-party Copy VPD page (see SPC-4) containing at least a Block Device ROD limits descriptor (see 6.x.x).

If the POPULATE TOKEN command causes one one ROD token to be created, then this ROD token may be retreived using the RECEIVE ROD TOKEN INFORMATION command. The RECEIVE ROD TOKEN INFORMATION command shall not return a block device zero ROD token (see 5.b.3). The WRITE USING TOKEN command causes data to be transferred from a ROD token created by the copy manager or from the block device zero ROD token. The copy manager manages the point in time data representation and the associated ROD token. After the copy manager begins processing a POPULATE TOKEN command or WRITE USING TOKEN command, the copy manager shall preserve information for return by a RECEIVE ROD TOKEN INFORMATION command (see 5.c) as defined in SPC-4.

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

Block device range descriptor lists (see 5.a.3) contain non-overlapping block device range descriptors and are used by the application client to specify: a) the logical blocks to include in the point in time data representation; b) the sequence of the logical blocks in the point in time data representation (e.g., the first logical block described in the first block device range descriptor is placed at the beginning of the point in time data representation, the first LBA described in the second block device range descriptor is placed in the point in time data representation immediately following the last LBA described in the first block device range descriptor); c) the logical blocks to be written from the point in time data representation; and d) the sequence of the logical blocks written from the point in time data representation (e.g., the first LBA described in the first block device range descriptor is written from the beginning of the point in time data representation, the first LBA described in the second block device range descriptor is written from data in the point in time data representation immediately following the data in the point in time data representation written to the last LBA described in the first block device range descriptor).
COUNT

If the copy manager uses out of order transfers to create the point in time data representation, then the TRANSFER field in the RECEIVE ROD TOKEN INFORMATION response for the POPULATE TOKEN command (see 5.c.2) shall be based only on the contiguous transfers that complete without error starting at the first block specified by the first block device range descriptor (i.e., any transfers completed without error beyond the first incomplete or unsuccessful transfer shall not contribute to the computation of the TRANSFER COUNT field).

If the copy manager uses out of order transfers to write from the point in time data representation, then the TRANSFER COUNT field in the RECEIVE ROD TOKEN INFORMATION response for WRITE USING TOKEN command (see 5.c.3) shall be based only on the contiguous transfers that complete without error starting at the first block specified by the first block device range descriptor (i.e., any transfers completed without error beyond the first incomplete or unsuccessful transfer shall not contribute to the computation of the TRANSFER COUNT field).

<...>
Table 5 SBC-3 commands that are allowed in the presence of various reservations Addressed logical unit has this type of persistent reservation held by another I_T nexus Command From any I_T nexus Write Exclusive Exclusive Access ... POPULATE TOKEN ... READ (6)/(10)/(12)/(16)/(32) ... RECEIVE ROD TOKEN INFORMATION ... WRITE (6)/(10)/(12)/(16)/(32) ... WRITE USING TOKEN ... conflict conflict allowed conflict conflict conflict conflict allowed conflict conflict See SPC-4 allowed conflict allowed allowed conflict allowed conflict allowed allowed conflict From From I_T nexus not registered registered I_T nexus Write Exclusive (RR all Exclusive Access types) - RR RR

Proposal - XCOPY Lite - Tokenized READ/WRITE

T10/11-059 r8

16 May 2011

<...>
Table 19 Associations between commands and CbCS permissions Command name
DATA READ

Permissions bit mask bits (a)

DATA WRITE PARM READ PARM WRITE PHY ACC

... POPULATE TOKEN ... RECEIVE ROD TOKEN INFORMATION ... WRITE USING TOKEN ... 1 See SPC-4 1

<...>
Table 25 Commands for direct-access block devices Command name ... POPULATE TOKEN ... RECEIVE ROD TOKEN INFORMATION ... WRITE USING TOKEN ... 83h/11h O yes 5.b 84/07h O no 5.c and SPC-4 83h/10h O yes 5.a Operation codea Typeb Protection information Reference

5.a POPULATE TOKEN command

5.a.1 POPULATE TOKEN command overview The POPULATE TOKEN command (see table a1) requests that the copy manager (see SPC-4): a) create a point in time data representation from the specified LBAs; b) create a ROD token; and c) associate the ROD token with the point in time data representation.

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011 Each logical block includes user data and may include protection information. Table a1 POPULATE TOKEN command Bit Byte 0 1 2 ... 5 6 ... 9 10 ... 13 14 15 Reserved
CONTROL GROUP NUMBER

T10/11-059 r8

4
OPERATION CODE

3 (83h)

Reserved Reserved (MSB)

LIST IDENTIFIER

SERVICE ACTION

(10h)

(LSB) (MSB)
PARAMETER LIST LENGTH

(LSB)

The OPERATION CODE field is defined in SPC-4 and shall be set to the value shown in table a1 for the POPULATE TOKEN command. The SERVICE ACTION field is defined in SPC-4 and shall be set to the value shown in table a1 for the POPULATE TOKEN command. The LIST IDENTIFIER field is defined in SPC-4. The list identifier shall be processed as if the LIST ID USAGE field (see SPC-4) is set to 00b. The PARAMETER LIST LENGTH field specifies the length in bytes of the parameter list that shall be sent from the application client to the copy manager. A PARAMETER LIST LENGTH set to zero specifies that no data shall be sent. This shall not be considered an error. See the PRE-FETCH (10) command (see 5.6) and 4.20 for the definition of the GROUP NUMBER field. The contents of the CONTROL byte are defined in SAM-5. 5.a.2 POPULATE TOKEN parameter list

Proposal - XCOPY Lite - Tokenized READ/WRITE

T10/11-059 r8 The parameter list for the POPULATE TOKEN command is shown in table a2. Table a2 POPULATE TOKEN parameter list Bit Byte 0 1 2 3 4 ... 7 8 ... 13 14 15 16 ... 31 ... n-15 ... n Block device range descriptor [last] (see table 4) Block device range descriptor [first] (see table 4) (MSB)
BLOCK DEVICE RANGE DESCRIPTOR LIST LENGTH

16 May 2011

7 (MSB)

2 (n-1)

POPULATE TOKEN DATA LENGTH

(LSB)
IMMED

Reserved Reserved (MSB)

INACTIVITY TIMEOUT

(LSB) Reserved

(n-15)

(LSB)

Block device range descriptor list

The POPULATE TOKEN DATA LENGTH field specifies the length in bytes of the following data that is available to be transferred from the data-out buffer. The populate token data length does not include the number of bytes in the POPULATE TOKEN DATA LENGTH field. If the POPULATE TOKEN DATA LENGTH field is less than 30, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. The immediate (IMMED) bit specifies when the copy manager shall return status for the POPULATE TOKEN command. If the IMMED bit is set to zero, then the copy manager shall process the POPULATE TOKEN command until all specified operations are complete or an error is detected. If the IMMED bit is set to one, then the copy manager: 1) 2) 3) 4) 5) shall validate the CDB (i.e., detect and report all errors in the CDB); shall transfer all the parameter data to the copy manager; may validate the parameter data; shall complete the POPULATE TOKEN command with GOOD status; and shall complete processing of all specified operations as a background operation (see SAM-5).

If the operations specified by a POPULATE TOKEN command are processed as a background operation, the copy manager shall not generate deferred errors (see SAM-5) to report the errors encountered, if any, during this processing. Instead, the error reports shall be made available to the application client through use of the RECEIVE ROD TOKEN INFORMATION command (see 5.c). 10 Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

The INACTIVITY TIMEOUT field specifies advisory data that is the number of seconds that the copy manager should wait for the next WRITE USING TOKEN (see 5.b) command that uses the ROD token created by the processing of this command before invalidating that ROD token due to expiration of this timeout. If the INACTIVITY TIMEOUT field is set to a value larger than the maximum inactivity timer in the Block Device ROD Limits ECOP descriptor (see 6.x.x.3), then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. The copy manager shall replace an inactivity timeout value that is set to zero with the value in the DEFAULT inactivity timer field in the Block Device ROD Limits ECOP descriptor. The BLOCK DEVICE RANGE DESCRIPTOR LIST LENGTH field specifies the length in bytes of the block device range descriptor list. The block device range descriptor list length should be a multiple of 16. If the block device range descriptor list length is not a multiple of 16, then the last block device range descriptor is incomplete and shall be ignored. If the block device range descriptor list length is less than 16, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. If the number of complete block device range descriptors is larger than the maximum range descriptors value in the Block Device ROD Limits ECOP descriptor, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to TOO MANY SEGMENT DESCRIPTORS. If the same LBA is included in more than one block device range descriptor, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. If the sum of the contents of the NUMBER OF LOGICAL BLOCKS fields in all of the complete block device range descriptors is larger than the maximum token transfer size value in the Block Device ROD Limits ECOP descriptor, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. 5.a.3 Block device range descriptor The Block device range descriptor is described in table a3. Table a3 Block device range descriptor Bit Byte 0 ... 7 8 ... 11 12 ... 15 The LOGICAL BLOCK ADDRESS field specifies the first LBA on which the copy manager shall operate for this block device range descriptor. The NUMBER OF LOGICAL BLOCKS field specifies the number of logical blocks that the copy manager shall operate on for this block device range descriptor beginning with the LBA specified by the LOGICAL BLOCK ADDRESS field. Processing of block device range descriptors with a number of logical blocks that is not a multiple of the optimal transfer length granularity in the Block Limits VPD page (see 6.5.3) may incur significant delays in processing. Proposal - XCOPY Lite - Tokenized READ/WRITE 11 Reserved (MSB)
NUMBER OF LOGICAL BLOCKS

7 (MSB)

LOGICAL BLOCK ADDRESS

(LSB)

(LSB)

T10/11-059 r8

16 May 2011

Processing of block device range descriptors with a number of logical blocks that exceeds the optimal transfer length in the Block Limits VPD page<?> may incur significant delays in processing. If the number of logical blocks is greater than the maximum transfer length in the Block Limits VPD page, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. If the NUMBER OF LOGICAL BLOCKS field is set to zero, then no operation shall occur for this block device range descriptor. This condition shall not be considered an error. If the LBA specified by the LOGICAL BLOCK ADDRESS field plus the number of logical blocks exceeds the capacity of the medium, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to LOGICAL BLOCK ADDRESS OUT OF RANGE.

5.b WRITE USING TOKEN command

5.b.1 WRITE USING TOKEN command overview The WRITE USING TOKEN command (see table b4) requests that the copy manager (see SPC-4) write user data and protection information, if any, from the point in time data representation associated with the specified ROD token to the specified LBAs. Each logical block written includes user data, and may include protection information. Table b4 WRITE USING TOKEN command Bit Byte 0 1 2 ... 5 6 ... 9 10 ... 13 14 15 Reserved
CONTROL GROUP NUMBER

4
OPERATION CODE

3 (83h)

Reserved Reserved (MSB)

LIST IDENTIFIER

SERVICE ACTION

(11h)

(LSB) (MSB)
PARAMETER LIST LENGTH

(LSB)

The OPERATION CODE field is defined in SPC-4 and shall be set to the value shown in table b4 for the WRITE USING TOKEN command. The SERVICE ACTION field is defined in SPC-4 and shall be set to the value shown in table b4 in for the WRITE USING TOKEN command. The LIST IDENTIFIER field is defined in SPC-4. The list identifier shall be processed as if the LIST ID USAGE field (see SPC-4) is set to 00b. The PARAMETER LIST LENGTH field specifies the length in bytes of the parameter list that shall be sent from the application client to the copy manager. A PARAMETER LIST LENGTH set to zero specifies that no data shall be sent. This shall not be considered an error.

12

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

See the PRE-FETCH (10) command (see 5.6) and 4.20 for the definition of the GROUP NUMBER field. The contents of the CONTROL byte are defined in SAM-5. 5.b.2 WRITE USING TOKEN parameter list The parameter list for the WRITE USING TOKEN command is shown in table b5. Table b5 WRITE USING TOKEN parameter list Bit Byte 0 1 2 3 ... 7 8 ... 15 16 ... 527 528 ... 533 534 535 536 ... 551 ... n-15 ... n The WRITE USING TOKEN DATA LENGTH field specifies the length in bytes of the data that is available to be transferred from the data-out buffer. The write using token data length does not include the number of bytes in the WRITE USING TOKEN DATA LENGTH field. If the WRITE USING TOKEN DATA LENGTH field is less than 550, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. Block device range descriptor [last] (see 5.a.3) Block device range descriptor [first] (see 5.a.3) (MSB)
BLOCK DEVICE RANGE DESCRIPTOR LIST LENGTH

7 (MSB)

2 (n-1)

WRITE USING TOKEN DATA LENGTH

(LSB)
IMMED

Reserved Reserved (MSB)

BLOCK OFFSET INTO ROD

(LSB) (MSB)
ROD TOKEN

(LSB)

Reserved

(n-535)

(LSB)

Block device range descriptor list

Proposal - XCOPY Lite - Tokenized READ/WRITE

13

T10/11-059 r8

16 May 2011

The immediate (IMMED) bit specifies when the copy manager shall return status for the WRITE USING TOKEN command. If the IMMED bit is set to zero, then the copy manager shall process the WRITE USING TOKEN command until all specified operations are complete or an error is detected. If the IMMED bit is set to one, then the copy manager: 1) 2) 3) 4) 5) shall validate the CDB (i.e., detect and report all errors in the CDB); shall transfer all the parameter data to the copy manager; may validate the parameter data; shall complete the WRITE USING TOKEN command with GOOD status; and shall complete processing of all specified operations as a background operation (see SAM-5).

If the operations specified by a WRITE USING TOKEN command are processed as a background operation, the copy manager shall not generate deferred errors (see SAM-5) to report the errors encountered, if any, during this processing. Instead, the error reports shall be made available to the application client through use of the RECEIVE ROD TOKEN INFORMATION command (see 5.c). The BLOCK OFFSET INTO ROD field specifies the offset, in logical blocks, from the first logical block in the point in time data representation to the first logical block to be transferred (e.g., if a point in time data representation created from logical blocks five to ten and 50 to 60 is referenced by a WRITE USING TOKEN command that specifies a BLOCK OFFSET INTO ROD field set to eight, then the first block transferred begins with the data that is in logical block 52 of the source from which the ROD was created). If the block offset into ROD specifies an offset that is greater than or equal to the number of logical blocks in the ROD, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. The ROD TOKEN field specifies the location from which user data and protection information, if any, is written to the media. The location is specified as follows: a) the point in time data representation ROD token returned by a RECEIVE ROD TOKEN INFORMATION command; or b) a block device zero ROD token. If there is no point in time data representation with which a matching ROD token is associated, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID TOKEN OPERATION, CAUSE NOT REPORTABLE. The BLOCK DEVICE RANGE DESCRIPTOR LIST LENGTH field specifies the length in bytes of the block device range descriptor list. The block device range descriptor list length should be a multiple of 16. If the block device range descriptor list length is not a multiple of 16, then the last block device range descriptor is incomplete and shall be ignored. If the block device range descriptor list length is less than 16, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. If the number of complete block device range descriptors is larger than the maximum range descriptors value in the Block Device ROD Limits ECOP descriptor (see 6.x.x.3), then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to TOO MANY SEGMENT DESCRIPTORS. If the same LBA is included in more than one block device range descriptor, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. If the sum of the contents of the NUMBER OF LOGICAL BLOCKS fields in all of the complete block device range descriptors is larger than the maximum token transfer size value in the Block Device ROD Limits ECOP descriptor, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN PARAMETER LIST. As part of completing the operation, the copy manager shall compute the residual by subtracting the sum of the contents of the NUMBER OF LOGICAL BLOCKS fields in all of the complete block device range descriptors of the WRITE USING TOKEN command from the transfer count (see 4.x.1). If the residual is negative, then the operation shall return sense data that contains CHECK CONDITION status with the sense key set to COPY ABORTED and the additional sense code set to COPY TARGET DEVICE UNDERRUN. 14 Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

If the sum of the contents of the NUMBER OF LOGICAL BLOCKS fields in all of the complete block device range descriptors is larger than the number of logical blocks in the ROD minus the block offset into ROD (i.e., the total requested length of the transfer exceeds the length of the data available in the ROD), then the copy manager shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to COPY TARGET DEVICE UNDERRUN. The copy manager may perform this check during the processing of each block device range descriptor. 5.b.3 Block device zero ROD token The Block device zero ROD token is associated with user data of all bits set to zero and protection information set to FFFF_FFFF_FFFF_FFFFh. The Block device zero ROD token format is shown in table C. Table C Block device zero ROD token format Bit Byte 0 ... 3 4 5 6 7 8 ... 511 (MSB) Reserved (LSB) (MSB)
ROD TOKEN LENGTH

7 (MSB)

ROD TOKEN TYPE

(FFFF_0001h) (LSB)

Reserved

(01F8h)

(LSB)

The ROD TOKEN TYPE field is defined in SPC-4 and shall be set to the value shown in table C for the Block device zero ROD token. The ROD TOKEN LENGTH field is defined in SPC-4 and shall be set to the value shown in table C for the Block device zero ROD token.

<...> 5.c RECEIVE ROD TOKEN INFORMATION command

5.c.1 RECEIVE ROD TOKEN INFORMATION overview The RECEIVE ROD TOKEN INFORMATION command (see SPC-4) provides a means for the application client to receive information about the results of a previous or current POPULATE TOKEN command (see 5.a) or WRITE USING TOKEN command (see 5.b).

Proposal - XCOPY Lite - Tokenized READ/WRITE

15

T10/11-059 r8

16 May 2011

<The following information is duplicated from SPC-4 (11-079) for reference only. This text is NOT to be included in SBC-3.> Table x1 RECEIVE ROD TOKEN INFORMATION command Bit Byte 0 1 2 5 6 9 10 13 14 15 (MSB) (MSB) Reserved
LIST IDENTIFIER

4
OPERATION CODE

3 (84h)

SERVICE ACTION

(07h) (LSB)

Reserved
ALLOCATION LENGTH

(LSB)

Reserved
CONTROL

The OPERATION CODE field is defined in SPC-4 and shall be set to the value shown in table x2 for the RECEIVE ROD TOKEN INFORMATION command. The SERVICE ACTION field is defined in SPC-4 and shall be set to the value shown table x2 for the RECEIVE ROD TOKEN INFORMATION command. The LIST IDENTIFIER field is defined in SPC-4. The ALLOCATION LENGTH field is defined in the GET LBA STATUS command (see 5.4). The contents of the CONTROL byte are defined in SAM-5. <This is the end of the reference only text duplicated from SPC-4 (11-079).>

16

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

5.c.2 RECEIVE ROD TOKEN INFORMATION parameter data for POPULATE TOKEN command Table x2 shows the parameter data returned by the copy manager in response to a RECEIVE ROD TOKEN INFORMATION command if the command received on the same I_T nexus with a list identifier that matches the list identifier specified in the RECEIVE ROD TOKEN INFORMATION CDB is a POPULATE TOKEN command. Table x2 RECEIVE ROD TOKEN INFORMATION parameter data for POPULATE TOKEN Bit Byte 0 3 4 5 6 7 8 11 12 13 14 15 16 23 24 25 26 31 32 x x+1 x+4 x+5 x+6 x+7 n (MSB) (MSB) (MSB) (MSB) Reserved (MSB) Reserved 7 (MSB) 6 5 4
AVAILABLE DATA

3 (n-3)

(LSB) (10h)

RESPONSE TO SERVICE ACTION COPY OPERATION STATUS OPERATION COUNTER

(LSB) (LSB)

ESTIMATED STATUS UPDATE DELAY EXTENDED COPY COMPLETION STATUS SENSE DATA FIELD LENGTH (X-31) SENSE DATA LENGTH TRANSFER COUNT UNITS TRANSFER COUNT

(F1h) (LSB)

SEGMENTS PROCESSED

(0000h)

(LSB)

Reserved
SENSE DATA

ROD TOKEN DESCRIPTORS LENGTH

(n-(x+4))

(LSB)

Restricted (see SPC-4)

ROD TOKEN

Editors Note 1: The above (offset x+5 / x+6) Restricted 2 byte field followed by the ROD TOKEN is the equivalent of a ROD token descriptor as shown in 11-079 which contains a 2 byte ID followed by the ROD TOKEN. For the POPULATE TOKEN command, the response does not contain an ID value for the ROD TOKEN, therefore those 2 bytes are restricted.

Proposal - XCOPY Lite - Tokenized READ/WRITE

17

T10/11-059 r8

16 May 2011

The AVAILABLE DATA field, COPY OPERATION STATUS field, OPERATION COUNTER field, ESTIMATED STATUS UPDATE DELAY field, EXTENDED COPY COMPLETION STATUS field, SENSE DATA FIELD LENGTH field, SENSE DATA LENGTH field, SENSE DATA field, and the ROD TOKEN field are defined in SPC-4. The RESPONSE TO SERVICE ACTION field is defined in SPC-4 and shall be set to the value shown in table x2 for the RECEIVE ROD TOKEN INFORMATION command in response to a POPULATE TOKEN command. The TRANSFER COUNT UNITS field is defined in SPC-4 and shall be set to the value shown in table x2 for the RECEIVE ROD TOKEN INFORMATION command in response to a POPULATE TOKEN command. The TRANSFER COUNT field indicates the number of contiguous logical blocks that were read without error from the media into the point in time data representation starting at the logical block address specified in the first block device range descriptor and including the LBAs described in all block device range descriptors of the POPULATE TOKEN command to which this response applies. If the TRANSFER COUNT field is not equal to the sum of the contents of the NUMBER OF LOGICAL BLOCKS fields in all of the complete block device range descriptors of the POPULATE TOKEN command to which this response applies then the COPY OPERATION STATUS field shall be set to 3h. The SEGMENTS PROCESSED field is defined in SPC-4 and shall be set to the value shown in table x2 for the RECEIVE ROD TOKEN INFORMATION command in response to a POPULATE TOKEN command. The ROD TOKEN DESCRIPTORS LENGTH field is defined in SPC-4 and shall be set to the size of the ROD TOKEN field plus two for the RECEIVE ROD TOKEN INFORMATION command in response to a POPULATE TOKEN command.

18

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

5.c.3 RECEIVE ROD TOKEN INFORMATION parameter data for WRITE USING TOKEN command Table x3 shows the parameter data returned by the copy manager in response to a RECEIVE ROD TOKEN INFORMATION command if the command received on the same I_T nexus with a list identifier that matches the list identifier specified in the RECEIVE ROD TOKEN INFORMATION CDB is WRITE USING TOKEN. Table x3 RECEIVE ROD TOKEN INFORMATION parameter data for WRITE USING TOKEN Bit Byte 0 3 4 5 6 7 8 11 12 13 14 15 16 23 24 25 26 31 32 n (MSB) (MSB) (MSB) Reserved (MSB) Reserved 7 (MSB) 6 5 4
AVAILABLE DATA

3 (n-3)

(LSB)

RESPONSE TO SERVICE ACTION(11h) COPY OPERATION STATUS OPERATION COUNTER

(LSB) (LSB)

ESTIMATED STATUS UPDATE DELAY EXTENDED COPY COMPLETION STATUS SENSE DATA FIELD LENGTH SENSE DATA LENGTH TRANSFER COUNT UNITS TRANSFER COUNT

(n-31)

(F1h) (LSB)

SEGMENTS PROCESSED

(0000h)

(LSB)

Reserved
SENSE DATA

The AVAILABLE DATA field, COPY OPERATION STATUS field, OPERATION COUNTER field, ESTIMATED STATUS UPDATE DELAY field, EXTENDED COPY COMPLETION STATUS field, SENSE DATA FIELD LENGTH field, SENSE DATA LENGTH field, and SENSE DATA field are defined in SPC-4. The RESPONSE TO SERVICE ACTION field is defined in SPC-4 and shall be set to the value shown in table x3 for the RECEIVE ROD TOKEN INFORMATION command in response to a WRITE USING TOKEN command. The TRANSFER COUNT UNITS field is defined in SPC-4 and shall be set to the value shown in table x3 for the RECEIVE ROD TOKEN INFORMATION command in response to a WRITE USING TOKEN command. The TRANSFER COUNT field indicates the number of contiguous logical blocks that were written without error from the point in time data representation to the media starting at the logical block address specified in the first block device range descriptor and including the LBAs described in all block device range descriptors of the WRITE USING TOKEN command to which this response applies. If the TRANSFER COUNT field is not equal to the sum of the contents of the NUMBER OF LOGICAL BLOCKS fields in all of the complete block device range descriptors of the WRITE USING TOKEN command to which this response applies then the COPY OPERATION STATUS field shall be set to 3h.

Proposal - XCOPY Lite - Tokenized READ/WRITE

19

T10/11-059 r8

16 May 2011

The SEGMENTS PROCESSED field is defined in SPC-4 and shall be set to the value shown in table x3 for the RECEIVE ROD TOKEN INFORMATION command in response to a WRITE USING TOKEN command.

20

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

6.5 Vital product data (VPD) parameters

6.5.1 VPD parameters overview This subclause defines the VPD pages used only with direct-access block devices. See SPC-4 for VPD pages used with all device types. The VPD pages and their corresponding page codes specific to direct-access block devices are defined in table 176. Table 176 Direct-access block device VPD page codes VPD page name Block Device Characteristics VPD page EXTENDED COPY OPERATING PARAMETERS (ECOP) Block Limits VPD page Logical Block Provisioning VPD page Referrals VPD page Reserved for this standard
a

Page code a B1h See SPC-4 B0h B2h B3h B4h to BFh

Reference 6.5.2 6.x.x 6.24.3 6.5.4 6.5.5

Support requirements Optional Optional b Optional Optional Optional

All page code and subpage code combinations for direct-access block devices not shown in this table are reserved. b Mandatory if the POPULATE TOKEN command and the WRITE USING TOKEN command are supported.

<...>
6.x.x EXTENDED COPY OPERATING PARAMETERS (ECOP) VPD page 6.x.x.1 ECOP VPD page overview The ECOP VPD page (see SPC-4) provides a means to retrieve ECOP descriptors including a descriptor that describes operating parameters for the POPULATE TOKEN command (see 5.a) and the WRITE USING TOKEN command (see 5.b). 6.x.x.2 Block Device ECOP descriptor type codes Block Device ECOP descriptor type codes (see table x15) indicate which ECOP descriptor is being returned. Table x15 Block Device ECOP descriptor type codes ECOP descriptor name Block Device ROD Limits See SPC-4
a

Page code 0000h All other codes

Reference 6.x.x.3

Support requirements Optional a

Mandatory if the POPULATE TOKEN command and the WRITE USING TOKEN command are supported.

6.x.x.3 Block Device ROD Limits ECOP descriptor The Block Device ROD Limits ECOP descriptor (see table d1) is an ECOP descriptor in the ECOP VPD page (see SPC-4) and provides the application client with the means to obtain certain operating parameters for block device ROD token operations (see 4.x). Proposal - XCOPY Lite - Tokenized READ/WRITE 21

T10/11-059 r8

16 May 2011

<note to reviewers - the ECOP VPD page is defined in 11-078 - it is replicated here only for reference, and is NOT to be included in SBC-3> Table xx ECOP VPD page Bit Byte 0 1 2 3 4 (MSB) 7 6
PERIPHERAL QUALIFIER PAGE CODE

2
PERIPHERAL DEVICE TYPE

(??h) (n-3) (LSB)

PAGE LENGTH

ECOP descriptors ECOP descriptor [first] . . . n ECOP descriptor [last]

<This is the end of the text that is for reference only> Table d1 Block Device ROD Limits ECOP descriptor Bit Byte 0 1 2 3 4 ... 9 10 11 12 ... 15 16 ... 19 (MSB)
DEFAULT INACTIVITY TIMER ECOP DESCRIPTOR TYPE

(0000h)

(MSB)

ECOP DESCRIPTOR LENGTH

(0020h)

(LSB)

Vendor specific

(MSB)

MAXIMUM RANGE DESCRIPTORS

(LSB)

(MSB)
MAXIMUM INACTIVITY TIMER

(LSB)

(LSB)

22

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011 Table d1 Block Device ROD Limits ECOP descriptor Bit Byte 20 ... 27 28 ... 35 (MSB)
OPTIMAL TRANSFER COUNT

T10/11-059 r8

7 (MSB)

MAXIMUM TOKEN TRANSFER SIZE

(LSB)

(LSB)

The ECOP DESCRIPTOR TYPE field and the ECOP DESCRIPTOR LENGTH field are defined in SPC-4 and shall be set to the values show in table d2. The MAXIMUM RANGE DESCRIPTORS field indicates the maximum number of block device range descriptors that may be specified in the parameter data of a POPULATE TOKEN command (see 5.a) and the parameter data of a WRITE USING TOKEN command (see 5.b). If the MAXIMUM RANGE DESCRIPTORS field is set to zero, then the copy manager does not report a maximum number of block device range descriptors. The MAXIMUM INACTIVITY TIMER field indicates the maximum value in the INACTIVITY TIMEOUT field of the parameter data of a POPULATE TOKEN command that is accepted by the copy manager. If the MAXIMUM INACTIVITY TIMER field is set to zero, then the device server does not report a maximum inactivity timeout value. If the MAXIMUM INACTIVITY TIMER field is set to FFFF_FFFFh then there is no maximum value that may be specified in the INACTIVITY TIMEOUT field in the parameter data of the POPULATE TOKEN command. The DEFAULT INACTIVITY TIMER field indicates the inactivity timeout value that is used if the INACTIVITY TIMEOUT field in the parameter data of a POPULATE TOKEN command is set to zero. If the DEFAULT INACTIVITY TIMER field is set to zero, then the copy manager does not report a default inactivity timeout value. The MAXIMUM TOKEN TRANSFER SIZE field indicates the maximum size in blocks that may be specified by: a) the sum of the NUMBER OF LOGICAL BLOCKS fields in all block device range descriptors of the POPULATE TOKEN command; and b) the sum of the NUMBER OF LOGICAL BLOCKS fields in all block device range descriptors of the WRITE USING TOKEN command. If the MAXIMUM TOKEN TRANSFER SIZE field is set to zero, then the copy manager does not report a maximum token transfer size. The OPTIMAL TRANSFER COUNT field indicates the optimal number of blocks that the copy manager is able to transfer. If the sum of the NUMBER OF LOGICAL BLOCKS fields in all block device range descriptors in the parameter data of a POPULATE TOKEN command or the parameter data of a WRITE USING TOKEN command exceeds this value then, a significant delay in processing the request may be incurred. If the OPTIMAL TRANSFER COUNT field is set to zero, then the copy manager does not report an optimal transfer count.

6.24.3 Block Limits VPD page

<...>
The OPTIMAL TRANSFER LENGTH GRANULARITY field indicates the optimal transfer length size granularity in blocks for a single ORWRITE command, PRE-FETCH command, READ command, VERIFY command, WRITE command, WRITE AND VERIFY command, XDREAD command, XDWRITE command, XDWRITEREAD command, or XPWRITE command listed in table 4a. Transfers with transfer lengths sizes not equal to a multiple of this value

Proposal - XCOPY Lite - Tokenized READ/WRITE

23

T10/11-059 r8

16 May 2011

may incur significant delays in processing. If the OPTIMAL TRANSFER LENGTH GRANULARITY field is set to zero, then the device server does not report optimal transfer length granularity. The MAXIMUM TRANSFER LENGTH field indicates the maximum transfer length size in blocks that the device server accepts for a single ORWRITE command, READ command, VERIFY command, WRITE command, WRITE AND VERIFY command, XDWRITEREAD command, or XPWRITE command listed in table 4a. If a device server receives a request for a transfer length size exceeding this maximum, then the device server shall terminate the command with CHECK CONDITION status with the sense key set to ILLEGAL REQUEST and the additional sense code set to INVALID FIELD IN CDBthe value shown in table 4a. If the device server sets the MAXIMUM TRANSFER LENGTH field to zero, then there is no reported limit on the transfer length. The OPTIMAL TRANSFER LENGTH field indicates the optimal transfer length size in blocks for a single ORWRITE command, PRE-FETCH command, READ command, VERIFY command, WRITE command, WRITE AND VERIFY command, XDREAD command, XDWRITE command, XDWRITEREAD command, or XPWRITE command listed in table 4a. If a device server receives a request with a transfer length size exceeding this value, then a significant delay in processing the request may be incurred. If the OPTIMAL TRANSFER LENGTH field is set to zero, then there is no reported optimal transfer lengthsize. Table 4a shows commands affected by transfer length values in the Block Limits VPD page. Table 4a VPD limited commands Field that specifies the transfer size Additional sense code (if required) when the value in the specified field exceeds the VPD page value

Command

ORWRITE PRE-FETCH READ VERIFY WRITE WRITE AND VERIFY XDREAD XDWRITE XDWRITEREAD XPWRITE any individual block device range descriptor in a POPULATE TOKEN command any individual block device range descriptor in a WRITE USING TOKEN command block device range descriptor NUMBER
OF LOGICAL BLOCKS

CDB TRANSFER LENGTH field

INVALID FIELD IN CDB

INVALID FIELD IN PARAMETER LIST

field

<...>

24

Proposal - XCOPY Lite - Tokenized READ/WRITE

16 May 2011

T10/11-059 r8

SPC-4 changes:
7.3.6 General Statistics and Performance log pages 7.3.6.1 Overview

<...>
In the General Statistics and Performance log page and the Group Statistics and Performance (n) log pages (see 7.3.7), read commands and write commands are those shown in table 5. Table 5 Statistics and Performance log pages commands Read commands a POPULATE TOKEN READ(6) READ(10) READ(12) READ(16) READ(32) Write commands a WRITE USING TOKEN UNMAP WRITE(6) WRITE(10) WRITE(12) WRITE(16) WRITE(32) WRITE AND VERIFY(10) WRITE AND VERIFY(12) WRITE AND VERIFY(16) WRITE AND VERIFY(32)

See SBC-3.

Proposal - XCOPY Lite - Tokenized READ/WRITE

25