2016-03-22 01:22 AM - edited 2016-03-22 02:48 AM
I created 2 LUNs, mounted as drive M and N via iSCSI, for copy test. (also tried to copy via cifs , but still works poorly)
While ODX is disabled, I copied a 50GB file from M to N , via File Explorer, it started at 2xx Mb/s and then down to even 1x MB/s some time later.
While ODX is enabled, still copied a 50GB file in same drive(no matter iscsi or cifs) , via File Explorer, sometimes it went up to 1.x GB/s and sometimes went down to 2xx MB/s.
How can it be so slow without ODX ?
Why the transfer rate didn’t keep stable 1.x GB/s as I seen in the YouTube demo https://www.youtube.com/watch?v=mFfAEEwNuUQ ?
What can I do to find out the root cause?
Thanks in advance.
My test environment:
FAS2240: 12x2TB SATA total, 3 for root aggr, and 9 for RAID-DP
Server: Dell PowerEdge R720
OS: Win2012r2 AD Server (clean installation) , Qlogic-10Gb card
Communication: direct attach through UTA 10Gb
In Win 2012r2 ,I use this command to disable ODX. "set-itemproperty hklm:\system\currentcontrolset\control\filesystem -name "FilterSupportedFeaturesMode" -value 1"
I also use "fltmc instances" to verify every filter supports ODX.
Solved! SEE THE SOLUTION
2016-03-22 01:55 AM
Without having any log data I'm making some assumptions, so take it as hints to verify, but here goes! Your hardware config is an entry level system with only 7 data disks of 2TB SATA. So not a lot of horsepower in the controller and with few slow disks. Becauase your ODX performance is fine I assume that your LUNs are located in the same volume. If this is true, then with ODX enabled the system is internally using cloning which only has to update metadata and not actually read or write any data blocks from the disks. With ODX disabled then the system has to read the data blocks from disks, send it to the host, and then the host had to write them back all the way to disk. So without ODX there is much more disk IOPs and CPU needed and my guess is you are hitting the limits of your config.
As a simple test you could check sysstat command on the node while running the test:
Watch the columns I've highlighted, and the CPU column I forgot to highlight, to see if one of these is at limit during your test. If from the above you are still stuck I would open a support case and provide a perfstat so they can better explain what is going on.
Hope this helps!
Storage Architect, NetApp EMEA (and author of Harvest)
Blog: It all begins with data
If this post resolved your issue, please help others by selecting ACCEPT AS SOLUTION or adding a KUDO