Author: Martin Zugec (31 Articles)
If you ask regular administrator that got experiences with scripting about his favorite scripting utilities that he is using even in combination with PowerShell today, I guess that many people will reply "Robocopy and PsTools of course". I am one of them – even though I don’t use pstools anymore, robocopy /MIR is one command whose equivalent is simply missing in Powershell.
There are few different versions of Robocopy though:
1.) XP010 – version from Resource Kit that is being used by most administrators
2.) XP026 – updated version, however it’s not easy to get it
3.) XP027 – new version built-into Windows Vista
4.) XP027 – new version built-into Windows 7
Have you noticed something strange? Points 3 and 4 are the same, so why are they mentioned?
Even though version number is the same, Windows 7 version of Robocopy contains some improvements – /MT parameter. Default value is 8, maximum allowed is 128.
With /MT, you can specify how many threads will robocopy use to copy files. I was really curious about these results, so I decided to give it a try and test how different versions of Robocopy compares. For each test I decided to do combination of following variables: files count, files size and number of threads.
First, let’s compare versions 10, 26 and 27. On horizontal, you can see amount of files (100, 1000 and 3000). Lower number is better (amount of time needed to copy those files).
As you can see, new version of robocopy was faster in most cases (expect copying 3000 x 1MB files).
Increase of speed is caused by multiple threads running – this is especially useful if you copy multiple small files.
Ok, so we have 8 threads now, does that mean that if I will increase them to 128, it will be fastest? Of course not Below you can find few graphs that I just run today – every line here represents different number of threads (8, 15 and 40):
As you can see, performance is not very stable and different combination of factors sometimes favors more and sometimes less threads. Therefore my recommendation – don’t mess with threads (unless you got static jobs that you run over and over) and simply enjoy the fact that it is faster
Suddenly, one scenario that could really benefit from multi-threading is not supported yet In robocopy, if file is locked and cannot be overwritten, robocopy will retry it over and over – by default 1.000.000 times with delay of 30 seconds between those retries. You would expect that in case of multi-threaded copy one thread will try it over and over and the rest would simply continue, however whole robocopy will hang. It would be nice to have additional switch to support this mode.
It’s also important to mention disadvantages\bugs of all versions of robocopy:
XP010 – too old There are some bugs related to mirroring security settings for example and of course performance was greatly improved in recent versions.
XP026 – NO ERRORLEVEL. There is bug in this version that doesn’t return correct errorlevels (it’s always 0). Not fixed as far as I know.
XP027 – runs only at Windows Vista. You cannot copy it over to XP\2003 server and use it there anymore
XP027 (Win7) – runs ONLY at Windows 7 – even if you try to copy it over to Windows Vista machine, it won’t help you at all (I will talk about this in detail in upcoming Win7 Inside Out article).
Don’t forget that graphs included in this post are just informative – I didn’t rerun them few times over and over, I just wanted to get quick idea how different is performance between versions.