Is it slower to copy two files at the same time than to copy one after the other? [duplicate]

My boss was saying it takes longer to copy two files at the same time than doing one and then the other because the hard drive has to keep switching the head between the two locations on disk. Is this true? It seems to me that the operating system should be smart enough to fix this (i.e., it should know to copy them sequentially). Is this true when copying to a drive connected to a USB port?

EDIT: are there any other factors regarding the files system that factors in? For example does it make a difference copying 1 directory containing 10 files versus copying 10 files from all over the disk? I'm wondering only about one source medium and one destination medium (no reading from multiple drives).

Solution 1:

I will defer you to this question. It seems that running two copy operations on the same disk concurrently (though started through separate copy operations) would indeed take longer as a result of the latency generated by the head seeking back and forth between the competing operations.

If, however, the copy operations are started simultaneously, the large majority of modern operating systems are as you said smart enough to en-queue the transfers one after the other, and should yield a somewhat quicker copy time.

There are apparently a number of applications available to force the file copy operations to queue and execute sequentially such as Teracopy and FastCopy

Performing concurrent copy operations on multiple physical volumes is another matter entirely, however. As is transferring files through alternate protocols.

Regarding your question about copying to a drive connected to a USB port, it is heavily dependent upon the type of memory that the drive uses and the USB spec being utilized (certainly a noteworthy bottleneck for USB 1.0 and 2.0), as well as the previously mentioned factors regarding the copy source volume.

Solution 2:

There are lots of factors here that could affect this.

• Source drive - is this spinning disk or SSD? If spinning disk, the layout of the files could affect performance. As the two files are likely on different parts of the disk, this will incur head seek penalties. As you said, if you select two files at once, and initiate the copy that way, the OS will handle the copies sequentially.
• File layout - fragmentation of the files (both on the source and the destination) could affect performance for non-SSD drives
• Destination - if you've got two write streams writing to a single target, then you're back to the head seek issue (again, assuming not an SSD), and you could heavily interleave the files. I used to work for a company that made high performance storage, and one of the big issues for them was how many real-time streams of video they could read or write (2k video requires ~300 megs a second). Alternating the writes will slow down the copy process, and would also make reading the file back slower. Of course, if your disk is fragmented to start, your file will be written interleaved anyway.
• single/multiple source/target - depending on if your files are all coming from one drive or all being written to a single drive, the head seek issue could be more or less
• file size - for really small files, the head seek issue won't matter, as the head would need to seek to find the next file anyway (meaning that instead of going back and forth between files, the head would be reading files sequentially)

As for if the OS is smart enough to fix this, in general, they are. That is, if you copy multiple files simultaneously (e.g. think of selecting multiple files at once and drag-n-drop).

Of course, if you kick off two cp commands, then it's going to run the two commands, or in Windows if you copy/paste separate files, and get two "copy" progress windows on the screen, then the optimization won't occur. In this case, you've explicitly told the OS that you want to run the two copies simultaneously, so it's not going to decide one copy is more important than the other and start queuing them.