We ran some tests comparing Robocopy with and without the /MT (multithread) option with local disk, 1GbE network and 10GbE network. We tested a variety of numbers and sizes of files. I gave a presentation at our local user group meeting, and the presentation is available at www.demartek.com/Demartek_Presenting_RMWTUG_March_2011-03.html. The /MT option provides improved performance and in some cases, significantly improved performance.Dennis29

I recently used robocopy to verify that a cloned volume was in sync with a production volume. Each volume was 2TB with 2.6 million files and was presented on a Server 2003 x64 VM (ESX 4). Robocopy xp_026 took 2.5 hours to crawl through the volume when I tested it with "/E /ZB /COPYALL /R:5 /W:3 /L" Perfmon showed a sustained ~99% disk time on the volume - I know the /MT option is only available in Win7 and 2008+, but how could running robocopy with /MT be faster if the disk is running 99% sustained activity with a single thread? Wouldn't requests from the additional threads just land in the disk queue? I read your results on the comparison between single and multi threaded operations, but it didn't explain what was happening on the disk and exactly why /MT was faster. Hoping you could shed some light ... thanks.

Without seeing the full scenario it would be hard to say exactly why you got the results you did. We're working on a larger robocopy report where we will do various tests with different settings such as repeating the same copies with different thread counts, etc. We will also have some full Perfmon data showing disk queue lengths, etc. Based on your scenario, we will also test inside a VM on VMware/ESX and Hyper-V to show the impacts of the hypervisors. What kind of disk drives and array do you have for your robocopy scenario?Dennis29