5

While copying large number of files, it's quite often to use multiple threads with RoboCopy (/MT[:n] option). Can this cause fragmentation on the destination drive? Sometimes I use Beyond compare for copying the file structures to maximum utilize the network/HDD bandwidth. This is also in a way of creating multiple threads. Can both of these cause fragmentation?

Improve this question
2
  • It depends on the size of the files you're copying. If you are copying a lot of smaller files, it makes sense to use threaded copying. If you are copying a lot of large files, you should probably avoid it. That being said, I couldn't find anything on the actual Microsoft website detailing this switch, so I don't know how much information you will find in regards to your question that isn't speculation (just warning you).
    – Breakthrough
    Jun 28, 2011 at 18:35
  • I just testing copying 50K+ photos to a new drive using the /MT (8 threads) option and surprisingly there is zero fragmentation.
    – user986363
    Jan 29, 2016 at 22:46

4 Answers 4

Reset to default
3

If you are unsure you can simply check the copied files if they are fragmented and if yes in how many fragments.

To check a file you can use "Contig" by Microsoft/Mark Russinovich which allows to check fragmentation using the switch -a

contig -a <filename>

http://technet.microsoft.com/en-us/sysinternals/bb897428.aspx

Improve this answer
2
  • Thank you. Are there any tools other than default defragmenter to defrag the file?
    – sarat
    Jul 4, 2011 at 9:15
  • 1
    Contig is designed to defragment certain files and folders. The fragment analyze function is just a side function.
    – Robert
    Jul 4, 2011 at 9:22
2

(Not an answer, but as a new user it appears that I can't directly comment on previous answers.)

In response to music2myear, multithreaded copies that do not preallocate space can indeed lead to to extreme fragmentation.

The scenario is this: fileA begins copying to block N on the disk. fileB begins copying to block N+1 on the disk. fileC begins copying to block N+2 on the disk. fileA needs another block, and copies to N+3. fileB needs another block and copies to N+4. And so on... until every file is completely fragmented, with no two blocks contiguous. fileA ends up being on blocks N,N+3,N+5,N+10,N+13 rather than N,N+1,N+2,N+3,N+4.

OK, so that's a little extreme; it probably doesn't become completely fragmented. But it illustrates the problem with multithreaded copy utilities that don't preallocate space. That said, I just tried the robocopy included with Server 2008R2 to copy a large number of files of varying sizes, and it didn't seem to create excess fragmentation. (Previous versions of robocopy were known to cause extreme fragmentation.) More testing is necessary.

Improve this answer
1
  • From personal experience, I run into fragmentation problem while running robocopy from Windows 10 recovery console trying to backup my data of 1TB hard drive (with BitLocker) into 8TB backup one. Robocopy began throwing errors that the volume is too fragmented to complete this operation.
    – mlt
    Apr 8, 2018 at 3:02
1

It should not cause any more fragmentation than a single-threaded copy operation which looks for the first available space and then the next and so on as it copies.

Any drive with high read/writes and larger or mixed-size files ought to be defragmented regularly, unless you're using a filesystem that prevents fragmentation.

If you are very concerned about fragmentation, you should consider the benefits you gain by using multithreading (extreme benefit for large numbers of files, less benefit for few larger files) versus any performance hit you may experience from possible fragmentation.

Improve this answer
0

i have seen this:

  • RE-FORMAT E: as FAT32 (format M: /FS:FAT32 /Q), so nothing is on it
  • List E: (dir /A E:) and nothing is on it
  • Copy only one file from D: to E: without doing anything else till ends
  • List E: (dir /A E:) and there is only such file
  • See fragmentation of E: and it is horrible, file start is in middle of the partition, and it is in a lot of fragments (more than 10)

i had also Tried with robocopy and no success, still fragment it.

if i try to defragment after copy, nothing is done.

How to avoid it? I got it by doing some extra steps... and using XCOPY /J command...

I got it by doing this:

  • RE-FORMAT E: as FAT32 (format M: /FS:FAT32 /Q), so nothing is on it
  • List E: (dir /A E:) and nothing is on it
  • Copy only one file from D: to E: without doing anything else till ends (XCOPY /J D:\TEMP\TheFile.TheExtension E:\AAA), yes renaming it as AAA at the same time
  • Rename it back to its real name (REN E:\AAA TheFile.TheExtension)
  • List E: (dir /A E:) and there is only such file
  • See fragmentation of E: and the file is just one fragment, no fragmentation at all

I had tried with "copy" and "robocopy" without succed.

I had tried with "XCOPY /J ... " and succed!!!

Why? i do not know... but at least with "XCOPY /J ... " and worked when dest name was changed!!!

It seems like Windows is doing some abnormal things when dest name is some kinf of special name.

To see what i mention just try to use a FAT32 4113MB partition to hold a 4095MB pagefile.sys!!! and try to have it on just one fragment!!! no way to do it normally!!! but, hey, if from a console you re-format the partition and use XCOPY /J pagefile.sys E:AAA and then rename it... it stays in one fragment!!!

Hope this can help other people!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .