Foo - Computer stuff: USB HDD to USB HDD copy, internal HDD used?

If two USB hard drives, A and B, are attached to my computer, and I copy files from A to B, does the computer's HDD get used or does the data go from A, into the computers motherboard and straight out to B without the computer's HDD being used?

Does it depend on the OS? If it helps, I'm using Windows 7 Beta VM on an OSX box, copying 300GB from A to B.

My guess is that it goes straight between the USB HD's. It does the transfer in segments and utilizes memory as the "middle man" between the drives. If your physical memory is low, it might start storing on the internal HD. But most computers these days have plenty of memory to handle this task, even with multiple applications open.

Corrections are probably needed and welcomed.

If you've got both drives mounted inside the Windows7 VM, the data should go from one drive-A's physical USB port to the VM's virtual-USB port. Then out to the other virtual-USB port to the physical USB port that drive-B is plugged into.

You may notice that this requires double the number of operations as copying it straight from drive-A to drive-B in the Mac's finder windows.

I believe what DannoXYZ says is correct. If not VMs were involved and just Windows, then it would have to route through the computer's USB bus, but not necessarily the hard drive. Throwing the VM in there only adds another layer of a virtual USB on each end which would connect to the regular USB.

Now it "could" use the hard drive to buffer some data, though I do not know that it would need to. Only guessing it is remotely possible. If its the VM though, it would be in the VM's virtual hard drive (e.g. the big VM file).

Another thing to consider is that the speed of the hard-drives are simply geological compared to the CPU's speed. During the copy operation, the CPU is waiting 99.9% of the time for the platter to spin the next sector under the heads. As such, having lots of memory to buffer and store the read from one drive before sending to the other one won't make much of a difference. Read-write buffering is typically less than 10mb on most modern OSes. If you buffer too much of a read before writing it out, you stand the risk of having some sort of incident that interrupts the write and you'll end up way behind the reading drive. This is also the risk with write-caching as well. Although on a lot of high-end systems, the write-cache is battery-backed and can hold the last write operations for up to 3-days before committing to the disk and maintain data-integrity.

So in a copy operation between two drives, regardless of interface, the data pretty much goes straight from one drive, sits in RAM for just a little bit and gets spit out to the 2nd drive. The rate-limiting step is the read as you must read the file sequentially and the data can only come off the platters so fast. Writes can typically be faster due to caching and command queuing and re-ordering to minimize head-movements.

Now you're just showing off.

That was:
a) Waaaaaay more than he wanted/needed to know.
and
b) Really irrelevant as he can't do anything to "change" those options. It's not like he can just go in and change the hard drive buffer size, for example.


Another thing to consider is that the speed of the hard-drives are simply geological compared to the CPU's speed. During the copy operation, the CPU is waiting 99.9% of the time for the platter to spin the next sector under the heads. As such, having lots of memory to buffer and store the read from one drive before sending to the other one won't make much of a difference. Read-write buffering is typically less than 10mb on most modern OSes. If you buffer too much of a read before writing it out, you stand the risk of having some sort of incident that interrupts the write and you'll end up way behind the reading drive. This is also the risk with write-caching as well. Although on a lot of high-end systems, the write-cache is battery-backed and can hold the last write operations for up to 3-days before committing to the disk and maintain data-integrity.

So in a copy operation between two drives, regardless of interface, the data pretty much goes straight from one drive, sits in RAM for just a little bit and gets spit out to the 2nd drive. The rate-limiting step is the read as you must read the file sequentially and the data can only come off the platters so fast. Writes can typically be faster due to caching and command queuing and re-ordering to minimize head-movements.

I'm not even sure why he was asking the original question?

I'm not even sure why he was asking the original question?

Me either....come to think of it. :p