Monthly Archives: October 2011

Slow file copy or slow file transfer with various Windows versions 2k8, 2k8R2, 2k3

There are various posts in the Microsoft Technet File Systems and Storage forum (and other forums) indicating slow file copy/transfer speed. The details vary, but most of them involve either Windows Server 2008, Windows Server 2008 R2, or Windows Server 2003. This document is an attempt to coalesce all the various solutions into a single place. Note that the author of this document has not personally tested any of the solutions, but various posts in the forum indicate these to have solved the problem for some users.

Symptom: File copy or File transfer speed is slow, either to a local drive or a network drive, especially so when a Windows Server 2008 or newer Windows file server is involved.

Possible Solutions in no particular Order

  • Make sure both IPv6 and IPv4 are running on 2008 R2, even if the 2008 R2 server is the lone IPv6 device on the network! There may be alternate solutions but this solution has been reported to work [1] [2]
  • Tune TCP on client – set autotuning to off “netsh interface tcp set global autotuninglevel=disabled” [2]
  • Tune TCP on client and server – turn off receive side scaling “netsh interface tcp set global rss=disabled” [3]
  • Tune TCP disable large send offload [5] [17]
  • Tune TCP disable large receive offload [11]
  • Tune TCP – disable  offload [5] [7][9] [11] [16]

Edit the registry key Edit the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters; create a new DWORD value named DisableTaskOffload and set its value to 1

  • Use non-cached writes while copying the file e.g. run Windows 7 xcopy which supports a new /J switch to do non-cached writes. The Microsoft Performance Team uses the Microsoft Exchange utility eseutil to copy files using non-cached writes. However, some Microsoft customers may not have Microsoft Exchange. Also, the legalities of copying files from a Microsoft Exchange server to a File Server as the Microsoft Performance Team blog in Reference [6] suggests are beyond the scope of this compilation of solutions. [6] [14]
  • Install all hotfixes from Microsoft [8]
  • Don’t use File Explorer to do copy/paste – and if you do, ensure Remote Differential Copy is turned off [4]
  • If one of the drives involved in the file copy is an external USB drive, ensure that you are using the USB 2 protocol and not the older slower USB 1. Start Device Manager, find USB Controller, clock USB2 Enhanced Controller Host, and right click properties; make sure it is enabled. Repeat these steps for all USB2 Enhanced controller hosts.
  • Make sure drive compression is turned off [10]
  • Make sure antivirus is fully updated or if possible, remove antivirus solutions from the equation to see if that is the cause [12]
  • Install all updated drivers from vendors especially NIC vendors and RAID drivers [13] [16]


  1. What causes Windows 2008 R2 slow file and folder copy
  2. Server 2008 R2 core slow file copy
  3. Windows 2008 R2 File and Folder Copy very slow over 1000MBs link
  4. Why is Windows 7 still as slow as Vista with File Copy
  5. Slow network file copy on Windows 7
  6. Slow large file copy issues  Microsoft Performance team blog
  7. Slow file copy between Vista and Small Biz Server 
  8. Low performance when you transfer files from external IEEE 1394 device to server
  9. Very slow DFSR on Windows Server 2008
  10. Server 2008 File transfer is slow
  11. File Copy very slow to Windows Server 2008 R2
  12. IPS driver causes network slowdown
  13. Network transfers start fast then slow down
  14. Windows 2008 R2 large file copy uses all available memory and slows down  
  15. Slow LAN transfer Windows Server 2008 R2 – enable IPv6
  16. Windows Server 2008 R2 file/folder copy/paste very slow 
  17. Windows 7 Large File copy painfully slow 



SMB 2.2 and other Windows 8 protocol documentation

With Windows 8, Microsoft is significantly pushing the envelope on Windows Server performance and high availability with Windows 8, while also enabling these features with low cost Network Attached Storage.

Recall the days when Microsoft was fined 2 million odd dollars per day for not publishing proper documentation for various protocols. What is remarkable is that while Windows 8 has not even reached a Beta stage, the documentation for the various different new protocols in Windows 8 has already been published at this MSDN link. In no particular order, here is a summary of the various storage and NAS protocols you will find at that MSDN link

  1. Windows 8 will support Hyper-V and SQL storing VHD files on an SMB 2.2 NAS share. A new File Server Remote VSS Protocol will enable shadow copy based backups (and restores) of these NAS shares.
  2. The new SMB 2.2 protocol that
    1. Allows clients to obtain leases on directories and not just files
    2. Extensions to the SMB 2 protocol that allow for a client to form multi-channel based multiple connections to a server and have the data flow in parallel across all channels, thus providing bandwidth aggregation as well resiliency by dropping down to remaining existing channels when a given channel fails
    3. Allows clients to retrieve hashes for ranges of a file – this SMB is used in branch cache scenarios
    4. A new SMB over RDMA protocol that allows for setting up and SMB 2 based client/server connection and the transferring data using an RDMA capable transport such as iWarp or Infiniband
    5. A Storage Services protocol that provides for scenarios such as creating modifying volumes and shares, creating and managing shadow copies, etc.

Notably absent so far is a new Witness Notification Protocol document that forms the basis for high availability NAS shares and is the basis of the highly significant enhancements to have clients transparently fail over to new servers/shares as needed, without needing to re-open files. Presumably, this document and other remaining documents will get posted soon.

Note that all of the documents are marked preliminary. This is not surprising, given that Windows 8 has not yet reached a Beta stage, and presumably Microsoft reserves the right to make modifications as needed

NTFS improvements for high availability in Windows 8

Caveat: While efforts are made to make the content accurate, you peruse the contents of this blog at your own risk and responsibility. Any actions you take, or do not take based upon the blog contents are also your own responsibility.

Microsoft has strived to improve NTFS resiliency and availability through the various versions of Windows. This post focusses on one aspect: the availability of an NTFS volume when corruption is detected.

Prior to Windows Server 2008 R2, when an NTFS volume corruption is detected, the volume is taken offline and a process known as Chkdsk run to fix the corruption. The amount of time Chkdsk took to run was somewhat proportional to the number of files and directories within the NTFS volume. Thus smarter administrators sized NTFS volumes in a way that limited the maximum amount of files and directories within a given volume. For some corporations, this meant additional NTFS volumes with the associated management overhead. Starting with Windows NT4 and up to Windows 2008, Microsoft invested in efforts to reduce the amount of time it took to run Chkdsk.

With Windows Server 2008 R2, Microsoft changed tack and focused on improving NTFS volume availability by:

  1. Further reducing the amount of time it took Chkdsk to run. In particular, this was done by reading NTFS meta data in bigger chunks and by better caching it, thus avoiding disk IOPS. Note that most of the time spent in Chkdsk is scanning the volume to detect issues, rather than in actually fixing the issues. This is where the time taken to run Chkdsk being proportional to the number of files & directories arises from.
  2. Reducing the frequency with which Chkdsk needed to run by better detection of whether the volume was corrupted or not
  3. Fixing at least some of the corruption issues without taking the volume off line, a process Microsoft termed “self healing

Windows 8 takes this logical progression a step further

  1. Scanning to detect errors is done while the volume is online and available.
  2. As in step 3 above, self healing fixes some of the corruption issues. Indications are that a further set of errors is fixed by self healing in Windows 8 as compared to prior versions of Windows
  3. The errors that cannot be corrected are logged
  4. The volume is taken offline and the errors identified in phase C are corrected. This implies the volume is unavailable only for the duration taken to fix the errors logged in phase C.
  5. In rare instances, the scanning determines that the corruption is too serious and needs a full offline scan, just as in Windows Server 2008 R2 and earlier versions of Windows.

Diagram 1 is a slide from a talk at the Windows 8 BUILD conference and the whole slide deck is available at this link

The item to note from the diagram is that the amount of time taken to fix a corrupted volume is now independent of the number of files and directories within the volume with one caveat. The caveat is that the corruption is not of an extremely serious nature – those still require the old style full scan while the volume is unavailable.

Microsoft now supports NTFS volumes of up to 24TB in size with Windows 8 and effectively, the number of files and directories within a given volume may also be increased without fear of the volume being unavailable for a long time due to corruption.

The changes in NTFS imply that an NTFS volume has more states in Windows 8 compared to prior versions of Windows. Tables 1 and 2 summarize the NTFS volume states in Windows 8 and prior versions of Windows

Table 1 Windows Server 2008R2/Windows 7 and earlier version of Windows NTFS volume states

NTFS Volume State 2k8R2/Win7 & earlier versions of Windows Description
Clean/Healthy “All is well” – no corrective action needed
Dirty/Potentially needs repair Can result even from an incorrect shutdown – indicates a scan and potential fixing needed

 Table 2 Windows 8 NTFS Volume states

Windows 8 NTFS volume states Description
Clean/Healthy “All is well” – no corrective action needed
Scan Needed/Dirty Indicates scan and potential fixing needed, but the scan will be done while the volume is mounted
Spotfix needed Scan has identified the errors, some were “self healed”, some marked for quick offline fixing, the volume needs to be briefly taken offline and the logged errors fixed
Full Chkdsk needed  The errors are too serious to spot fix and an old style full scan with the volume being offline for a longer time is needed. Presumably this happens only rarely.

 Note that NTFS volumes are still “compatible” – you can take an NTFS volume created with prior versions of Windows and mount it on a Windows 8 system. You can also take an NTFS volume created with Windows 8 and use it with earlier versions of Windows.