“Slow” File Copy Issues


A recent performance issue case revolved around slow disk access times, and the impact that this had on Hyper-V and Windows in general.

The customer had identified that one of their SAN units was dramatically out performing another one, even though the slower unit should have been orders of magnitude faster – well, at least on paper!

As part of their tests IOMeter was used along with copying large files (20 – 30GB) from servers to and from the offending SAN.  The customer quickly noted that the Windows file copy was performing poorly in terms of throughput and memory consumption on the server.  So this had to be a Windows problem, right?  Well not really Smile

So what was going on?  There was already a great reference written up on the askperf blog where the explanation of the copy buffering was discussed.  Please hop on over to that site, subscribe to the RSS feed, and read the article. 

How to efficiently perform the copy test then?  Eseutil.exe was the weapon of choice to copy large files around, which is the reason for addition the capability to Exchange in the first place.  The syntax is shown below:


Even though it is trivial to get this working on non-Exchange servers it is still work, and may require change requests to be filed out.  If you don’t like completing such paper work, then you should be happy to hear that Windows 7 & 2008 R2 now have this capability built in.  The XCOPY command has a new switch, the  /J which will perform an un-buffered copy. 


And specifically the /J





Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *