t10 Xcopy Lite

25
16 May 2011 T10/11-059 r8 Proposal - XCOPY Lite - Tokenized READ/WRITE 1 To: INCITS Technical Committee T10 From: Fred Knight, NetApp Rajeev Nagar, Microsoft Bryan Matthew, Microsoft Daniel Suman, Dell Lazarus Vekiarides, Dell Email: [email protected] [email protected] [email protected] [email protected] [email protected] 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

Transcript of t10 Xcopy Lite

Page 1: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 1

To: INCITS Technical Committee T10From: Fred Knight, NetApp

Rajeev Nagar, MicrosoftBryan Matthew, MicrosoftDaniel Suman, DellLazarus Vekiarides, Dell

Email: [email protected]@[email protected][email protected][email protected]

Date: 16 May 2011Subject: SBC-3/SPC-4 - XCOPY Lite - Tokenized operations

1) Revision historyRevision 0 (Jan 10, 2011)Revision 1 (Feb 1, 2011) Incorporate feedback receivedRevision 2 (Feb 4, 2011) Incorporate changes from Feb 4 con-callRevision 3 (Feb 18, 2011) Incorporate changes from Feb 18 con-callRevision 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 timerFix some typosMake 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 descriptorPut 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 documentssam5r6 - SCSI Architecture Model - 5

Page 2: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

2 Proposal - XCOPY Lite - Tokenized READ/WRITE

sbc3r26 – SCSI Block Commands – 3spc4r29 – SCSI Primary Commands - 411-078r3 - Basic Extended Copy Upgrades11-079r4 - Byte Agglomeration Objects11-080r1 - Byte Agglomeration Tokens

3) OverviewHosts 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:

Page 3: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 3

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.

 

LUN B LUN A 

SCSI Target Device 

Named 

Area 2 

PROXY 

READ 

PROXY 

WRITE 

Named

Area 1 

(copy) 

Page 4: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

4 Proposal - XCOPY Lite - Tokenized READ/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

 SCSI Target Device 

Named  

Area 1 

(LBA 

pointers)

Named 

Area 2 

PROXY 

READ 

PROXY 

WRITE 

LUN B LUN A 

Page 5: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 5

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

Page 6: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

6 Proposal - XCOPY Lite - Tokenized READ/WRITE

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 Redundant Array of Independent DisksROD Representation of Data (see SPC-4)RBC 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) POPULATE TOKEN command (see 5.a);b) WRITE USING TOKEN (see 5.b) command ;c) RECEIVE ROD TOKEN INFORMATION command (see 5.c and SPC-4); andd) 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.

Page 7: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 7

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

If the copy manager uses out of order transfers to create the point in time data representation, then the TRANSFER COUNT 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

Command

Addressed logical unit has this type of persistent reservation held by another I_T nexus

From any I_T nexusFrom

registered I_T nexus

(RR all types)

From I_T nexus not registered

Write Exclusive

Exclusive Access

Write Exclusive

- RR

Exclusive Access -

RR

...

POPULATE TOKEN allowed conflict allowed allowed conflict

...

READ (6)/(10)/(12)/(16)/(32) allowed conflict allowed allowed conflict

...

RECEIVE ROD TOKEN INFORMATION See SPC-4

...

WRITE (6)/(10)/(12)/(16)/(32) conflict conflict allowed conflict conflict

...

WRITE USING TOKEN conflict conflict allowed conflict conflict

...

Page 8: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

8 Proposal - XCOPY Lite - Tokenized READ/WRITE

<...>

<...>

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; andc) associate the ROD token with the point in time data representation.

Table 19 — Associations between commands and CbCS permissions

Command namePermissions bit mask bits (a)

DATA READ DATA WRITE PARM READ PARM WRITE PHY ACC

...

POPULATE TOKEN 1

...

RECEIVE ROD TOKEN INFORMATION See SPC-4

...

WRITE USING TOKEN 1

...

Table 25 — Commands for direct-access block devices

Command name Operation codea Typeb Protection information

Reference

...

POPULATE TOKEN 83h/10h O yes 5.a

...

RECEIVE ROD TOKEN INFORMATION 84/07h O no 5.c and SPC-4

...

WRITE USING TOKEN 83h/11h O yes 5.b

...

Page 9: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 9

Each logical block includes user data and may include protection information.

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

Table a1 — POPULATE TOKEN command

BitByte

7 6 5 4 3 2 1 0

0 OPERATION CODE (83h)

1 Reserved SERVICE ACTION (10h)

2

Reserved...

5

6 (MSB)

LIST IDENTIFIER...

9 (LSB)

10 (MSB)

PARAMETER LIST LENGTH...

13 (LSB)

14 Reserved GROUP NUMBER

15 CONTROL

Page 10: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

10 Proposal - XCOPY Lite - Tokenized READ/WRITE

The parameter list for the POPULATE TOKEN command is shown in table a2.

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) shall validate the CDB (i.e., detect and report all errors in the CDB);2) shall transfer all the parameter data to the copy manager;3) may validate the parameter data;4) shall complete the POPULATE TOKEN command with GOOD status; and5) 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 copymanager shall not generate deferred errors (see SAM-5) to report the errors encountered, if any, during thisprocessing. Instead, the error reports shall be made available to the application client through use of the RECEIVEROD TOKEN INFORMATION command (see 5.c).

Table a2 — POPULATE TOKEN parameter list

BitByte

7 6 5 4 3 2 1 0

0 (MSB)POPULATE TOKEN DATA LENGTH (n-1)

1 (LSB)

2 Reserved IMMED

3 Reserved

4 (MSB)

INACTIVITY TIMEOUT...

7 (LSB)

8

Reserved...

13

14 (MSB)BLOCK DEVICE RANGE DESCRIPTOR LIST LENGTH (n-15)

15 (LSB)

Block device range descriptor list

16

Block device range descriptor [first] (see table 4)...

31

...

n-15

Block device range descriptor [last] (see table 4)...

n

Page 11: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 11

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.

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.

Table a3 — Block device range descriptor

BitByte

7 6 5 4 3 2 1 0

0 (MSB)

LOGICAL BLOCK ADDRESS...

7 (LSB)

8 (MSB)

NUMBER OF LOGICAL BLOCKS...

11 (LSB)

12

Reserved...

15

Page 12: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

12 Proposal - XCOPY Lite - Tokenized READ/WRITE

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.

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.

Table b4 — WRITE USING TOKEN command

BitByte

7 6 5 4 3 2 1 0

0 OPERATION CODE (83h)

1 Reserved SERVICE ACTION (11h)

2

Reserved...

5

6 (MSB)

LIST IDENTIFIER...

9 (LSB)

10 (MSB)

PARAMETER LIST LENGTH...

13 (LSB)

14 Reserved GROUP NUMBER

15 CONTROL

Page 13: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 13

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.

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.

Table b5 — WRITE USING TOKEN parameter list

BitByte

7 6 5 4 3 2 1 0

0 (MSB)WRITE USING TOKEN DATA LENGTH (n-1)

1 (LSB)

2 Reserved IMMED

3

Reserved...

7

8 (MSB)

BLOCK OFFSET INTO ROD...

15 (LSB)

16 (MSB)

ROD TOKEN...

527 (LSB)

528

Reserved...

533

534 (MSB)BLOCK DEVICE RANGE DESCRIPTOR LIST LENGTH (n-535)

535 (LSB)

Block device range descriptor list

536

Block device range descriptor [first] (see 5.a.3)...

551

...

n-15

Block device range descriptor [last] (see 5.a.3)...

n

Page 14: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

14 Proposal - XCOPY Lite - Tokenized READ/WRITE

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) shall validate the CDB (i.e., detect and report all errors in the CDB);2) shall transfer all the parameter data to the copy manager;3) may validate the parameter data;4) shall complete the WRITE USING TOKEN command with GOOD status; and5) 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, thecopy manager shall not generate deferred errors (see SAM-5) to report the errors encountered, if any, during thisprocessing. Instead, the error reports shall be made available to the application client through use of the RECEIVEROD 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 timedata representation to the first logical block to be transferred (e.g., if a point in time data representation createdfrom logical blocks five to ten and 50 to 60 is referenced by a WRITE USING TOKEN command that specifies aBLOCK OFFSET INTO ROD field set to eight, then the first block transferred begins with the data that is in logical block52 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 theROD, then the copy manager shall terminate the command with CHECK CONDITION status with the sense key setto 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.

Page 15: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 15

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 setto FFFF_FFFF_FFFF_FFFFh. The Block device zero ROD token format is shown in table C.

The ROD TOKEN TYPE field is defined in SPC-4 and shall be set to the value shown in table C for the Block devicezero 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 devicezero 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 toreceive information about the results of a previous or current POPULATE TOKEN command (see 5.a) or WRITEUSING TOKEN command (see 5.b).

Table C — Block device zero ROD token format

BitByte

7 6 5 4 3 2 1 0

0 (MSB)

ROD TOKEN TYPE (FFFF_0001h)...

3 (LSB)

4Reserved

5

6 (MSB)ROD TOKEN LENGTH (01F8h)

7 (LSB)

8 (MSB)

Reserved...

511 (LSB)

Page 16: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

16 Proposal - XCOPY Lite - Tokenized READ/WRITE

<The following information is duplicated from SPC-4 (11-079) for reference only. This text is NOT to be included in SBC-3.>

The OPERATION CODE field is defined in SPC-4 and shall be set to the value shown in table x2 for the RECEIVEROD 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).>

Table x1 — RECEIVE ROD TOKEN INFORMATION command

BitByte

7 6 5 4 3 2 1 0

0 OPERATION CODE (84h)

1 Reserved SERVICE ACTION (07h)

2 (MSB)LIST IDENTIFIER

5 (LSB)

6Reserved

9

10 (MSB)ALLOCATION LENGTH

13 (LSB)

14 Reserved

15 CONTROL

Page 17: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 17

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 TOKENINFORMATION command if the command received on the same I_T nexus with a list identifier that matches the listidentifier specified in the RECEIVE ROD TOKEN INFORMATION CDB is a POPULATE TOKEN command.

Editor’s 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.

Table x2 — RECEIVE ROD TOKEN INFORMATION parameter data for POPULATE TOKEN

BitByte

7 6 5 4 3 2 1 0

0 (MSB)AVAILABLE DATA (n-3)

3 (LSB)

4 Reserved RESPONSE TO SERVICE ACTION (10h)

5 Reserved COPY OPERATION STATUS

6 (MSB)OPERATION COUNTER

7 (LSB)

8 (MSB)ESTIMATED STATUS UPDATE DELAY

11 (LSB)

12 EXTENDED COPY COMPLETION STATUS

13 SENSE DATA FIELD LENGTH (X-31)

14 SENSE DATA LENGTH

15 TRANSFER COUNT UNITS (F1h)

16 (MSB)TRANSFER COUNT

23 (LSB)

24 (MSB)SEGMENTS PROCESSED (0000h)

25 (LSB)

26Reserved

31

32SENSE DATA

x

x+1 (MSB)ROD TOKEN DESCRIPTORS LENGTH (n-(x+4))

x+4 (LSB)

x+5Restricted (see SPC-4)

x+6

x+7ROD TOKEN

n

Page 18: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

18 Proposal - XCOPY Lite - Tokenized READ/WRITE

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 theRECEIVE 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 theRECEIVE 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 theRECEIVE 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 fieldplus two for the RECEIVE ROD TOKEN INFORMATION command in response to a POPULATE TOKENcommand.

Page 19: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 19

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 TOKENINFORMATION command if the command received on the same I_T nexus with a list identifier that matches the listidentifier specified in the RECEIVE ROD TOKEN INFORMATION CDB is WRITE USING TOKEN.

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

Table x3 — RECEIVE ROD TOKEN INFORMATION parameter data for WRITE USING TOKEN

BitByte

7 6 5 4 3 2 1 0

0 (MSB)AVAILABLE DATA (n-3)

3 (LSB)

4 Reserved RESPONSE TO SERVICE ACTION(11h)

5 Reserved COPY OPERATION STATUS

6 (MSB)OPERATION COUNTER

7 (LSB)

8 (MSB)ESTIMATED STATUS UPDATE DELAY

11 (LSB)

12 EXTENDED COPY COMPLETION STATUS

13 SENSE DATA FIELD LENGTH (n-31)

14 SENSE DATA LENGTH

15 TRANSFER COUNT UNITS (F1h)

16 (MSB)TRANSFER COUNT

23 (LSB)

24 (MSB)SEGMENTS PROCESSED (0000h)

25 (LSB)

26Reserved

31

32SENSE DATA

n

Page 20: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

20 Proposal - XCOPY Lite - Tokenized READ/WRITE

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

Page 21: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 21

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.

<...>

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 thatdescribes operating parameters for the POPULATE TOKEN command (see 5.a) and the WRITE USING TOKENcommand (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.

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

Table 176 — Direct-access block device VPD page codes

VPD page name Page code a ReferenceSupport

requirements

Block Device Characteristics VPD page B1h 6.5.2 Optional

EXTENDED COPY OPERATING PARAMETERS (ECOP)

See SPC-4 6.x.x Optional b

Block Limits VPD page B0h 6.24.3 Optional

Logical Block Provisioning VPD page B2h 6.5.4 Optional

Referrals VPD page B3h 6.5.5 Optional

Reserved for this standard B4h to BFh

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

Table x15 — Block Device ECOP descriptor type codes

ECOP descriptor name Page code Reference Support requirements

Block Device ROD Limits 0000h 6.x.x.3 Optional a

See SPC-4 All other codesa Mandatory if the POPULATE TOKEN command and the WRITE USING TOKEN command are

supported.

Page 22: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

22 Proposal - XCOPY Lite - Tokenized READ/WRITE

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

<This is the end of the text that is for reference only>

Table xx — ECOP VPD page

BitByte

7 6 5 4 3 2 1 0

0 PERIPHERAL QUALIFIER PERIPHERAL DEVICE TYPE

1 PAGE CODE (??h)

2 (MSB)PAGE LENGTH (n-3)

3 (LSB)

ECOP descriptors

4ECOP descriptor [first]

.

.

.

ECOP descriptor [last]n

Table d1 — Block Device ROD Limits ECOP descriptor

BitByte

7 6 5 4 3 2 1 0

0ECOP DESCRIPTOR TYPE (0000h)

1

2 (MSB)ECOP DESCRIPTOR LENGTH (0020h)

3 (LSB)

4

Vendor specific...

9

10 (MSB)MAXIMUM RANGE DESCRIPTORS

11 (LSB)

12 (MSB)

MAXIMUM INACTIVITY TIMER...

15 (LSB)

16 (MSB)

DEFAULT INACTIVITY TIMER...

19 (LSB)

Page 23: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 23

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

20 (MSB)

MAXIMUM TOKEN TRANSFER SIZE...

27 (LSB)

28 (MSB)

OPTIMAL TRANSFER COUNT...

35 (LSB)

Table d1 — Block Device ROD Limits ECOP descriptor

BitByte

7 6 5 4 3 2 1 0

Page 24: t10 Xcopy Lite

T10/11-059 r8 16 May 2011

24 Proposal - XCOPY Lite - Tokenized READ/WRITE

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

CommandField that specifies the transfer size

Additional sense code (if required) when the value in the specified field exceeds the VPD page value

ORWRITE

CDB TRANSFER LENGTH field

INVALID FIELD IN CDB

PRE-FETCH

READ

VERIFY

WRITE

WRITE AND VERIFY

XDREAD

XDWRITE

XDWRITEREAD

XPWRITE

any individual block device range descriptor in a POPULATE TOKEN command

block device range descriptor NUMBER OF LOGICAL BLOCKS field

INVALID FIELD IN PARAMETER LISTany individual block device range

descriptor in a WRITE USING TOKEN command

Page 25: t10 Xcopy Lite

16 May 2011 T10/11-059 r8

Proposal - XCOPY Lite - Tokenized READ/WRITE 25

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 (see7.3.7), read commands and write commands are those shown in table 5.

Table 5 — Statistics and Performance log pages commands

Read commands a Write commands a

POPULATE TOKENREAD(6)READ(10)READ(12)READ(16)READ(32)

WRITE USING TOKENUNMAPWRITE(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)

a See SBC-3.