Resolving a problem with offloaded data transfer

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 MicrosoftWindows.
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 are capable of ODX.
Verify that both the source and destination volumes that are involved are from the same IBM disk array. ODX can be initiated across any two volumes that are served by the same Lenovo Storage V7000 clustered system.
Check if ODX is enabled, or if any filter does not support it.
1. Check the registry value to determine whether ODX is enabled. Run the command Get-ItemPropertyhklm:\system\currentcontrolset\control\filesystem-Name"FilterSupportedFeaturesMode" to obtain the registry value.
  For example, on a Windows PowerShell command prompt:
```
PS C:\Users\Administrator> Get-ItemPropertyhklm:\system\currentcontrolset\control\filesystem-Name"FilterSupportedFeaturesMode"
FilterSupportedFeaturesMode : 0
```
  If the value is 0, ODX is enabled. If the value is 1, ODX is disabled.
2. If ODX is disabled, enable it by running the following command:
```
Set-ItemPropertyhklm:\system\currentcontrolset\control\filesystem-Name"FilterSupportedFeaturesMode"-Value0
```
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.
1. 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-vvolume
```
  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-vF:
```
  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:
1. Install Microsoft process monitor.
2. Start Microsoft process monitor and start capturing before you attempt ODX.
3. When Microsoft process monitor is ready, initiate the operation that initiates ODX.
4. 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 IBM 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/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.