When copying/transferring files on your computer from drive A to drive B, which drive is doing the “reading” and which drive is doing the “writing”? What determines the rate of transfer if hard drive A is say, an SSD and hard drive B is a HDD?
In: Technology
> When copying/transferring files on your computer from drive A to drive B, which drive is doing the “reading” and which drive is doing the “writing”?
Drive A is reading, drive B is writing [1]. How could it be otherwise?
> What determines the rate of transfer if hard drive A is say, an SSD and hard drive B is a HDD?
Whichever disk is slower [2] [3], which is probably the HDD.
[1] Writing actually involves a small amount of reading, since the OS keeps a “table of contents” of which parts of the disk are unused. As a file being written grows beyond the part of the disk currently assigned to it, the OS has to read the table of contents to find unused parts of the disk to put the additional incoming data.
[2] Actually the OS will use unused RAM to store copies of files (or parts of files) that have recently been read (“caches”) and data that has not yet been written to disk (“buffers”).
Suppose you write a program that generates some data and writes it to a small file on a slow disk. You know based on the disk’s physical specs that it would take 2 seconds to write this amount of data. However when you run the program, you measure how long it takes to write the data to disk, and it actually only takes 0.01 seconds, how can this be?
The answer is your program doesn’t literally “write the data to disk.” What it actually does is “tell the OS to write the data to the disk.” The OS doesn’t write the data to disk immediately, it copies it to an OS buffer first. This buffer’s in memory, and memory is very fast, that’s why your program only spends 0.01 seconds in the OS code that copies the data to the buffer. The OS spends the next 2 seconds slowly writing the data to disk in the background, *while your program continues to perform useful work* — basically having the buffer is a performance improvement since it keeps your program from waiting on a slow disk.
Effectively the OS tells your program a “white lie” that yep, the data’s been written and your program can continue about its business. When in actual fact this isn’t strictly true, the process of actually physically getting the data onto the disk is still on-going. Of course running programs can’t observe the truth of what’s physically happening on the disk, because the OS doesn’t allow programs to talk to the disk themselves. A program can only read or write files by asking the OS. So if a program asks the OS to read part of a file that’s just been written, but hasn’t yet been updated on-disk, the OS can give it the data from the memory buffer. And the magic trick, the illusion of an impossibly fast disk, is complete. The OS is lying, but all the running programs see the same behavior they would if the OS was telling the truth and the system somehow had a really fast disk. The lie doesn’t really affect the system’s functionality. Everything still works correctly, but programs that talk to the disk run faster!
The only way the illusion can break down is some disruptive event, like the entire system loses power, or the user physically removes the disk while there’s data in buffers waiting to be written. This is a big reason why problems can happen after not shutting down cleanly, or not using the “Safely remove disk” option before removing a USB drive or SD card.
If you write a very large file, larger than your system’s unused RAM, the buffers eventually fill up. Then the OS will have no choice but to make your program wait until some of those buffers empty. So you will end up being limited by the write speed of the disk.
[3] Similar stuff happens in the “read” direction. If you have a small file that’s been recently used, the OS has likely kept a copy of the file in its buffers. So even though physically reading the file from the disk might be very slow, your program might be able to get the data extremely quickly if the OS happens to already have a copy in memory.
Again, if your file is much larger than the amount of unused RAM, the caches will only be able to keep a small part of the file, and anything that reads the entire file will end up being limited by the read speed of the disk.
Think of this as two people. One holds a book (Drive A) and reads it aloud to the second person, which is copying and writing it down(Drive B).
It won’t matter how fast Drive A can read it, if Drive B can’t write at the same speed that Drive A is reading.
The drive you’re copying from is reading while the other one is writing.
The speed is determined by the weakest link, ie the slower of the two drives (specifically the source drive’s reading speed vs. the target drive’s writing speed).
Latest Answers