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:
For more information on Offloaded Data Transfers, please refer to
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 and="" both="" offload="" read="" span="" supports="" 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:
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.
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:
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.
http://technet.microsoft.com/en-in/library/jj200627.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/dn265439(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848056(v=vs.85).aspx
Published By
S.G.Godwin Dinesh
Sr.System Administrator
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.
For more information on Offloaded Data Transfers, please refer to
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 and="" both="" offload="" read="" span="" supports="" 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\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.
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 1Or, 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 clustersOther references:
Recommended hotfixes and updates for Windows Server 2012 R2-based failover clusters
http://technet.microsoft.com/en-in/library/jj200627.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/dn265439(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848056(v=vs.85).aspx
Published By
S.G.Godwin Dinesh
Sr.System Administrator
No comments:
Post a Comment