When Microsoft offloaded data transfer (ODX)
is enabled on a system, it is possible to encounter problems. These procedures help you address some
common issues that might arise.
The following issues might arise when ODX is enabled on a system:
- ODX is not working for a volume or volumes, or ODX is not getting initiated from Microsoft
Windows.
- ODX performance is not as expected.
- Existing read/write workload latency increases.
ODX is not working for a volume or volumes
Complete the following steps if ODX is not working for a volume or volumes.
- Check whether a specific volume is NTFS formatted. Only NTFS volumes can initiate or enable
ODX.
- Verify that both the source and destination volumes that are involved are from the same system
disk array. ODX can be initiated across any two volumes that are served by the same system.
- Check if ODX is enabled, or if any filter does not support it.
- Check the registry value to determine whether ODX is enabled. Run the command
Get-ItemProperty
hklm:\system\currentcontrolset\control\filesystem
-Name
"FilterSupportedFeaturesMode" to obtain the registry value.
For example, on a
Windows PowerShell command prompt:
PS C:\Users\Administrator> Get-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode"
FilterSupportedFeaturesMode : 0
If the value is 0, ODX is enabled. If the value is 1, ODX
is disabled.
- If ODX is disabled, enable it by running the following command:
Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" -Value 0
- Validate that the file system filter drivers that are attached to the volume support ODX.
Certain Windows filters do not support ODX. If these
filters are enabled for a specific volume or volumes, Windows does not initiate ODX.
- To validate file system filter driver opt-in status, list all of the file system filter drivers
that are attached to the volume on which you want to run ODX.
Open a Windows PowerShell session as an administrator, and then type the following
command where
volume is the drive letter of the volume:
Fltmc instances -v volume
For
example, to check whether the configuration is correct, run the following command where
volume is the drive letter for the VDisk that is formatted to
NTFS:
Fltmc instances -v F:
The
following output is an example of the result:
Instances for F: volume:
Filter Altitude Instance Name Frame SprtFtrs
-------------- ------------ ---------------------- ----- --------
TSFairShare 400010 TSFairShare Instance 0 00000000 --> Shows ODX incapability. You need to disable this filter.
PROCMON23 385200 Process Monitor 23 Instance 0 00000003 --> The "3" in the end means ODX read/write capability.
- Ensure that Windows is initiating ODX. To check that
ODX is indeed getting initiated from your Windows host:
- Install Microsoft process monitor.
- Start Microsoft process monitor and start capturing
before you attempt ODX.
- When Microsoft process monitor is ready, initiate the
operation that initiates ODX.
- Search the process monitor capture for the following commands:
FSCTL_OFFLOAD_WRITE
FSCTL_OFFLOAD_READ
Note: Windows initiates ODX only for transfers greater
than 256 K.
ODX performance is not as expected
ODX performance is dependent upon various parameters.
- Verify that ODX is getting initiated for the copy operation by using the steps that are outlined
in the previous section.
- If the ODX is initiated, but performance does not appear optimal, then make sure that both the
source and destination volumes that are involved in offloaded copy:
- Are served by the same system disk array (across array ODX is not supported).
- Have an NTFS cluster size greater than or equal to 32 K (that is, greater than or equal to a 32
K allocation unit)
- Offload performance depends upon various parameters such as:
- Controller side utilization due to other workloads.
- Whether Windows initiates the offload operations in
parallel.
Existing read/write workload latency increases
Workloads other than copy can experience higher latencies if the copy workload is high. The
latency occurs because the offload jobs tend to be bigger in size and tend to complete faster.
Therefore, they require more controller resources in a specific time slice. If the preference is to
have existing workloads not experience extra latency due to copy offload rather than the copy
offload benefits, then consider the following options:
- Revisit the capacity that is planned to accommodate offloaded copies.
Note: Host side CPU or
network bandwidth is freed up due to ODX, but it might add to the latency - depending upon the
amount of copy work that is offloaded to controller.
- Disable system-wide ODX by using the CLI.