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"

  • How much are you copying versus how much free memory do you have in your computer?
    – KCotreau
    Jul 26, 2011 at 6:33
  • PC -> USB-FLASH drive: several hundred GBytes free -> few GBytes free Jul 26, 2011 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, 2011 at 6:44
  • so you're advising me to use the "sync" command more often? Jul 26, 2011 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, 2011 at 6:54

4 Answers 4


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.

  • Also keep in mind it is a flash drive. It's hardware was never optimized for speed, but rather affordability.
    – surfasb
    Jul 26, 2011 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? Jul 26, 2011 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, 2011 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, 2011 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, 2014 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.

  • 2
    I'm writing a 12 Gig 7zip file to a brand new USB 3.0 flash drive formatted as NTFS. It was going about 100 MB/s for the first minute then dropped to 25ish MB/s for about a minute, then dropped to 11 or so for about 10 minutes. It wasn't a gradual downward slope, it was 3 distinct plateaus.
    – Eric
    May 15, 2018 at 13:40
  • I was copying the archive off my old i7 laptop with 16 Gigs of RAM. Copying this same 7zip archive off of the same thumbdrive on my new Xeon laptop with 32 Gigs of RAM took 2 minutes and there was no drop off in speed.
    – Eric
    May 15, 2018 at 14:01

I was suffering from this on OSX and managed to improve things significantly. First I stopped the Spotlight Index from trying to index the target drive. I then stopped thumbnail generation on the target drive (copying 55K images)

And finally I gave up using the GUI and switched to the command line using rsync -a source target

There are probably similar things you can do for other operating systems along these lines.


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.

  • 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, 2016 at 20:55
  • 3
    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, 2016 at 22:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.