Currently Being Moderated
lwei

ODX Under the Hood

Posted by lwei in Pseudo Benchmark on Mar 17, 2013 5:35:13 PM

Offloaded Data Transfer (ODX) is a new innovation in Windows 8 and Windows 2012. Traditionally, when a host needs to do a copy operation, the host first read the data from the source location in a storage device to a host buffer, then write the data in the buffer to the destination in the same or a different storage device. In other words, the host is in the midst of the copy operation; the data has to go through the host during a copy operation.


ODX shortens the data path of a copy operation. In fact, it takes the host out of the data path and enables the data to be transferred from the source to the destination in storage devices. Therefore, it is sometimes also called “copy offload”.

 

That sounds great. But, how does ODX do that? ODX uses three new SCSI commands to carry out copy offload. These three new commands are listed in Table 1, together with the READ and WRITE commands used in traditional copy operations.


Table 1. Three new SCSI commands.

Copy Offload

Traditional Copy

POPULATE TOKEN

READ

WRITE WITH TOKEN

WRITE

RECEIVE ROD TOKEN INFORMATION

N/A

 

Note that a token is a data descriptor. And a ROD token is a token that satisfies certain criteria, such as uniqueness and point-in-timeness. ROD is the abbreviation for Representation of Data.


From Table 1 we can see that the role of POPULATE TOKEN is similar to that of READ and WRITE WITH TOKEN is similar to WRITE in the traditional copy operation. The third command, RECEIVE ROD TOKEN INFORMATION, has no correspondence. But its role can be easily understood by using the analogy of outsourcing. In an outsourcing scenario, you scope out the job and have somebody else do it. You don’t do the work; but you are anxious about the progress or status. So, you request a status report. Likewise, in copy offloading, the host offloads or outsources the copy job to the storage. To obtain the status, the host issues a particular request, which causes the RECEIVE ROD TOKEN INFORMATION command to be sent to the storage device, which in turn sends the status back to the host.

 

Next, let’s go through the copy offload process step by step. But first of all, we need to understand the step-wise process of traditional copy.


Traditional Copy

 

Table 2 below outlines the simplified process of a traditional or normal copy.

 

Table 2. Normal copy process (simplified).

Step

Description

1

Host Read

2

SCSI READ

3

Data transfer from source LUN to host buffer

4

Host Write

5

SCSI WRITE

6

Data transfer from the buffer to destination LUN

 

Note that data has been transferred from storage to host in Step 3 and from host to storage in Step 6.

 

Copy Offload

 

Table 3 below shows the simplified process of copy offloading.

 

Table 3. Copy offload process (simplified).

Step

Description

1

Host Offload_Read

2

SCSI POPULATE TOKEN

3

A ROD token is created inside storage (the SCSI target device)

4

Host Offload_Read Reply

5

SCSI RECEIVE ROD TOKEN INFORATION

6

The ROD token is passed from storage to the host

7

Host Offload_Write

8

The ROD token is passed to storage

9

SCSI WRITE WITH TOKEN

10

Data transfer from source LUN to Destination LUN (data movement occurs inside storage, bypassing the host)

11

Host Offload_Write Reply

12

SCSI RECEIVE ROD TOKEN INFORATION

13

The copy status and result are returned to the host

 

Clearly, the copy offload process is more complex than that of the traditional copy. However, the benefit is that the data to be copied does not move from storage to host or vise versa. Only ROD Tokens travel between storage and host. However, the size of a ROD token is only 512 bytes, regardless of the amount of data to be copied.


The three new SCSI commands are defined or specified in the T10/T11 XCOPY Lite proposal, of which Fred Knight of NetApp was the first author. By the way, Fred was one of the four recipients of the 2012 INCITS Technical Excellence Award

 

Under the hood, ODX technology was built on the foundation of SCSI. As such, it can seamlessly tap into the SCSI infrastructure. For instance, a Windows 8 host can send a LUN an INQUIRY command to find out if the LUN is ODX capable. If so, copy offload can be utilized. Otherwise, the traditional copy will be used.

 

Because ODX was built on SCSI, it is easy to see why ODX is supported using storage protocols of Fibre Channel (FC), Fibre Channel over Ethernet (FCoE), Serial Attached SCSI (SAS) and iSCSI; but is not supported while using SATA. Thus, ODX provides another good answer to the question: Is SCSI Dead? ODX is a great demonstration that SCSI is alive and well.

 

 

Thanks for reading.

Comments

Filter Blog

By date:
By tag: