Offloaded Data Transfer (ODX)

Similar to vStorage APIs for Array Integration (VAAI) in VMware, ODX speeds up the movement and creation of blocks and files, which makes it a great feature to have in a Hyper-V virtualized environment. 

What is Offloaded Data Transfer (ODX)?
Imagine you have two servers that are connected to the same SAN, where both servers are using it for file storage. You want to move or copy a file from Server1 to Server2. At a high level, this is what happens:

Server1 reads the file from the SAN a bit at a time
Server1 sends the file, a bit at a time, to Server2 over the LAN

Server2 sends the bits of the file back to the SAN to be stored
It seems like a waste to send a file over the relatively latent LAN to transfer it from one LUN to another LUN on the same SAN. With ODX the middle man process is removed. 
Server1 coordinates with the SAN and Server2 via a token handover. The SAN takes up the load and performs a file copy without sending the file over the LAN. This greatly speeds up data movement between servers on the same SAN.

There are other scenarios where ODX offloads data transfer from Windows to the SAN. What if a server needs to copy a file? That file copy is offloaded to the SAN. What if a Hyper-V host needs to create or extend a newly fixed virtual hard disk? That can take quite some time, but not if ODX offloads the zeroing out process. And what if you want to convert VMware virtual machines into Hyper-V virtual machines? ODX will help, even more so if you happen to use NetApp MAT to do the work.

System Requirements

The first and most important component is the SAN. You must have a SAN that is certified for Windows Offloaded Data Transfer and is connected to your servers using one of the following:

Fibre Channel
Fibre Channel over Ethernet
Serial Attached SCSI (SAS)
You can copy between different arrays if the copy manager for the storage arrays supports cross-storage array ODX. In addition, the storage arrays must be from the same vendor.

Your physical machines that are performing the copy must be running Windows Server 2012 R2, Windows Server 2012, Windows 8.1, or Windows 8.

Any file system filter drivers must opt-in to ODX or doesn't prevent ODX. Non-supporting filters include Windows Server data deduplication and BitLocker. Pay attention to data replication and anti-malware products. The volumes must be unencrypted and Storage Spaces is not supported. The volume must be NTFS, and ReFS is not supported.

Note that you can build a Scale-Out File Server (SOFS) using a SAN that offers ODX. The SOFS nodes are connected to the SAN using legacy data protocols, and application servers connect to the SOFS using SMB 3.0. Data movement to the SAN can be optimized using ODX by the SAN.

Regarding the files -- they must be 256 KB or larger to be eligible for optimization. Highly-fragmented files will naturally hurt performance.

Enabling and Disabling ODX

ODX is enabled by default and will be used by Windows Server, including Hyper-V, when compatible storage and eligible operations are discovered. This, unfortunately, has led to issues with allegedly compatible SANs, such as HP's 3Par that could cause VHD/X data corruption, where this issue should be resolved with up-to-date installations.

You can disable ODX with a registry edit with the following PowerShell cmdlet (note that a value of 1 disables ODX):  
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem -Name FilterSupportedFeaturesMode” -Value 1

A reboot is required after setting this value.

Unfortunately, being on the Windows Server HCL doesn't guarantee anything with hardware enhancements, such as ODX and VMQ. I would recommend testing your storage system with and without ODX enabled.

Performance Gains from Using ODX

It's hard to compare storage performance between sites because there are always lots of variables that impact the tests. Dell's storage systems were much faster with ODX running, while the HP systems had a more modest gain.

Back to Blog