Partager via

Is Offloaded Data Transfers (ODX) working?

  • Article

Offloaded Data Transfers (ODX) is a new data transfer strategy that makes advancements in moving files.  Only storage devices that comply with the SPC4 and SBC3 specifications will work with this feature.  With this feature, copying files from one server to another is much quicker.  This feature is only available in Windows 8/2012 and above as both the source and the destination.

This is how it works at very high level:

  • A user copies or moves a file by using Windows Explorer, a command line interface, or as part of a virtual machine migration.
  • Windows Server 2012/2012R2 automatically translates this transfer request into an ODX (if supported by the storage array) and it receives a token that represents the data.
  • The token is copied between the source server and destination server.
  • The token is delivered to the storage array.
  • The storage array internally performs the copy or move and provides status information to the user.

Below is a picture representation of what it looks like.  The top box is the way we are used to seeing it.  If you copy a file from one machine to another, the entire file is copied over the network.  In the bottom box, you see that the token is passed between the machines and the data is transferred on the storage.  This makes copying files tremendously faster, especially if these files are in the gigabytes.

image

For more information on Offloaded Data Transfers, please refer to

Windows Offloaded Data Transfers Overview

Many Windows installations have additional filter drivers loaded on the Storage stack.  This could be antivirus, backup agents, encryption agents, etc.  So you will need to determine if the installed filter drivers support ODX.  As a quick note, if the filter driver supports ODX, but the storage does not (or vice versa), then ODX will not be used.

We have filter manager supported features (SprtFtrs) which will tell if filter drivers support ODX.  We can use the FLTMC command, as shown below, to list filter drivers and their supported features.  For example:

X:\> fltmc instances
Filter Volume Name Altitude Instance Name Frame SprtFtrs
---------- ------------- --------- ------------- ----- --------
FileInfo C: 45000 FileInfo 0 00000003
FileInfo I: 45000 FileInfo 0 00000003
FileInfo D: 45000 FileInfo 0 00000003 <-It supports both Offload Read and Write
FileInfo K: 45000 FileInfo 0 00000003
FileInfo \Device\Mup 45000 FileInfo 0 00000003

You can also see the Supported Features available for a filter driver in the registry:

HKLM\system\CurrentControlset\services\<FilterName>

The SupportedFeatures registry value contains an entry. If it is 3 as in the above FLTMC output, is supports ODX.

Now that we have determined that ODX is supported by the required components, is it actually working?  You can see the ODX commands FSCTL_OFFLOAD_WRITE and FSCTL_OFFLOAD_READ captured in a Process Monitor trace when it is working.  When ODX is working, we see the following in Process Monitor.

clip_image001

In case a target fails the Offload, it does not support ODX, or does not recognize the token, it can give a STATUS_INVALID_TOKEN and/or STATUS_INVALID_DEVICE_REQUEST as the result.

Other reasons why it might not work :

1)    Something above Storage stack such as encryption or File system driver (Encryption filter, etc.) can cause it to fail.
2)    Even though two disks/volumes might support offload they might be incompatible. This has to be established by involving the Storage Vendors.

It is not a recommendation, but for informational purposes, you can disable ODX functionality in the registry if so desired.  You can do this  with a PowerShell command:

Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" -Value 1

Or, you can edit the registry directly.  The value of 1 (false) means that it is disabled while the value of 0 (true) means it is enabled.  When this change is made, you will need to reboot the system for it to take effect.

One last thing to mention is that you should always keep current on hotfixes.  This is especially true if you are running Failover Clustering.  Below are the recommended hotfixes you should be running on Clusters, which include fixes for ODX.

Recommended hotfixes and updates for Windows Server 2012-based failover clusters
Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters

Other references:
https://technet.microsoft.com/en-in/library/jj200627.aspx
https://msdn.microsoft.com/en-us/library/windows/hardware/dn265439(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/hh848056(v=vs.85).aspx

Shasank Prasad
Senior Support Escalation Engineer
Microsoft Corporation

Comments

  • Anonymous
    January 01, 2003
    Hi.

    The link to the Windows Offloaded Data Transfers Overview is wrong. This is the correct one I assume:http://technet.microsoft.com/en-us/library/hh831628.aspx
  • Anonymous
    January 01, 2003
    thanks
  • Anonymous
    January 01, 2003
    @Martin Edelius (Atea)
    Thanks, the link was actually broken in the blog. But it is fixed now.
  • Anonymous
    January 01, 2003
    Thanks! Building my http://www.spectra.com/hp/used-storage/index.htm and probably spending the whole month setting it up.
  • Anonymous
    May 06, 2015
    https://msdn.microsoft.com/en-us/library/windows/hardware/dn265439%28v=vs.85%29.aspx

    For offload writes, the above Microsoft document states:

    "When a synchronous offload write command is sent to the target device, Windows expects the copy manager to complete the command within 4 seconds. If the command is terminated because of command time-out or other error conditions, Windows fails the command. The application falls back to the legacy copy operation according to the returned status code."

    The SRB timeout on the offload write is 60 seconds. I've simulated letting the command take 8 seconds to complete and ODX still stays engaged. Is there a document that more clearly details what happens if offload writes take more than 4 seconds? Is this a registry configurable value? Thanks.
  • Anonymous
    January 19, 2016
    Hi i have a small problem that i am encountering every time i try to enable the ODX i get an error,
    "Get-ItemProperty : a parameter could not be found that matches the parameter name 'Value. '"

    i am not sure wat i am doing wrong here..any advice would be appreciated..
    • Anonymous
      March 21, 2016
      You can simply make the changes to the below mentioned registry location and make sure that value for "FilterSupportedFeaturesMode" registry entry is 0Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem\