Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After a few minutes of copying, it just gets slower and slower. Why?

e.g. It starts with 20 MByte/sec, and when it finishes with it, it's @10 MByte/s.

Various files, big, small, etc.

UPDATE: question is regarding various operating systems, so it's a "general question"

share|improve this question
    
How much are you copying versus how much free memory do you have in your computer? – KCotreau Jul 26 '11 at 6:33
    
PC -> USB-FLASH drive: several hundred GBytes free -> few GBytes free – LanceBaynes Jul 26 '11 at 6:40
1  
I suspect that you have files cached in memory at first so they transfer quickly, and then once they start being moved from the hard drive, it slows down. I can't be sure in your case though. – KCotreau Jul 26 '11 at 6:44
    
so you're advising me to use the "sync" command more often? – LanceBaynes Jul 26 '11 at 6:45
    
I don't understand what you mean by the sync command. You gave no context to the question. I am not even sure what OS. – KCotreau Jul 26 '11 at 6:54

This behaviour is not specific to your flash drive, you can see this with hard drives as well. It has to do with the caching mechanism most operating systems and disks employ to speed up small writes.

The 20mb/s you see is the data being written to the disk cache (usually quick but small memory). Once this cache is full it must be flushed to disk - and now you're being bottlenecked by the slower disk.

Example 1: The effect is really pronounced when you have a controller with a large cache (like good RAID5 controller) where ~500mb of data can be cached quickly before it must be flushed to the disk.

Example 2: You can see the cache at play if you pull the flash drive out at the same time the file copy "finished". At this point in time your file is split between the disk and the cache - so the copy is "finished" as far as the operating system is concerned but the disk controller still needs to write what's left in the cache to the disk. If you put the flash drive back in and inspect the file you'll see it's not all there.

Disclaimer: These examples won't work if you don't have write caching enabled in your operating system/on the disk.

Further, if it's not disk caching at work then it's likely that what you're seeing is an effect of fragmentation. As the disk gets fuller and fuller less contiguous free space is available and the file system has to work harder to find places to put your files.

share|improve this answer
    
Also keep in mind it is a flash drive. It's hardware was never optimized for speed, but rather affordability. – surfasb Jul 26 '11 at 7:45
    
I don't think that would explain why the performance would decrease during long file copies. Rather performance would decrease over the life of the drive, yes? – ta.speot.is Jul 26 '11 at 8:55
    
It makes perfect sense. They are optimized for burst speeds, not sustained operations. Think of the average size of files being loaded onto flash drives. Would you optimize for a 30 second long file transfer or optimize for a 2 second long transfer? Add that onto of your two examples, and it explains plenty. – surfasb Jul 26 '11 at 12:58
    
It's like when you try to cram two people through an average door at a time. At first, you can calculate. Wow, I went from zero people through that door to two at a time. My speed is great. Then the line gets longer and your sampling gets better and you finally realize that small sample = bad math. . . – surfasb Jul 26 '11 at 13:00
    
@ta.speot.is I suppose this disk cache you mentioned is handled by OS on hard disk and is different from the hardware cache which hard drives have internally,right? – sepehr Feb 26 '14 at 9:24

While caching does cause some of this, it is not the only factor. If caching were the only factor, then we would expect the write speed to quickly drop from several hundred MB/s to the drive's actual write speed very rapidly, and stay there for the rest of the write. However, this is not what I have observed when performing large transfers to and from the disk (e.g. burning boot images). Instead, what I observe is that the speed gradually decreases over the course of the entire operation.

This slowdown is caused by data remanence on the flash chip(s) used to store the data necessitating that some of the blocks be written to more than once.

Inside a flash chip, there are block of data that can be written to. When writing, there are only two things that the computer can do: it can erase an entire block, or change some (or all) of the bits in a block from 0 to 1.

However, some of those block are better than others, especially so in lower-quality flash drives, and as a result when writing new data to it, some of the bits can sometimes switch back to 0 by themselves right after being written, and don't change. Thus, when writing to a block, the OS needs to check to make sure that all of the data was written correctly, and if it wasn't it has to redo the block by writing the same data to the same block two or three times until the data sticks.

So, when your computer is writing a bunch of data to the flash drive, here is a (not completely accurate, but good enough) explanation for how it does that:

  1. Take the first set of blocks to be written, and write them all.
  2. Read back all of the blocks we just wrote, and make a list of the ones that don't match
  3. Write the next set of blocks, along with the ones that weren't written correctly last time.
  4. Repeat 2-3 until all of the blocks have been written correctly.

When the computer is writing to the drive, it is reporting the rate at which it is writing blocks to the drive for the first time. Since it will also have to rewrite earlier blocks at the same time, the total throughput that can be used for virgin blocks goes down as the number of rewrites that also need to happen increases. Thus, the apparent write speed decreases over time.

share|improve this answer

You are completely wrong and must be a Novice. When file is written to a drive be it a flash USB drive or a hard drive the data is NOT/NEVER read back to see if it matches. That would take for ever. verification of the write is done by the hardware (Cyclic Redundancy check)and if an error occurs, it is posted back to the application from the hardware detected an error. The stalling that occurs and slows down (even to a pause) is caused by the CPU writing faster than the device can handle it. You will not find this happening to internal hard drives. You will never see what is really happening on a Windows OS but on Linux you can actually see that the CPU pauses until the USB hardware says OK to continue

share|improve this answer
    
The difference in write speeds of different storage devices can be extreme, for example compare the write speed of an old SD card to the write speed of a SATA III SSD. – karel May 31 at 20:55
    
Please refrain from personal insults. While your post may be correct, you must edit it to comply with our community standards. – Ben N May 31 at 22:36

You must log in to answer this question.

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