5 ms·

Unless he tried to copy the same file to the same USB stick on a machine with a different OS, the question should be "Can anyone explain why copying files to a

Unless he tried to copy the same file to the same USB stick on a machine with a different OS, the question should be "Can anyone explain why copying files to a USB stick takes so long?" The most likely answer is that the USB stick itself is pretty slow at writing incoming data into its internal flash modules. He also ought to test writing to a USB hard drive (with the physical spinning spindle inside) and I'd be surprised if his throughput would be less than 100Mbps even with a crappy drive.

Dylan16807 15y ago
I haven't seen a USB stick that was slower than 2-6 megabytes per second on large-file transfers. Dropping an order of magnitude of speed on smaller files is entirely windows' fault.
- vetinari 15y ago
  Windows uses two modes for USB devices - cached and uncached. When you plug USB stick, it is uncached by default. It was done this way, because most users do not bother with disconnecting the device and just pull the stick from USB port (and then they are surprised, that their files are not there). You can change the defaults in device properties, if you want caching on USB stick. I can show you an USB stick, that is slower than 2 MB/s. :(
  - Dylan16807 15y ago
    I am aware of the distinction windows makes there. But it's artificial to make such a thing binary. If it cached but only for a fraction of a second, with queue reordering to speed things up, it would still be safe to unplug right after a copy completes.
    - vetinari 15y ago
      You can't do time-based caching like this. Block is either written, or it is not. When you flush your cache, you don't know how long it will take. Even if your cache it is only fraction of second old. That's why there used to be performance problems in apps with fsync().
      - Dylan16807 15y ago
        What I'm saying is that you make it so as soon as the light stops blinking it's safe to remove. That means that you can have a cache as long as you flush it almost immediately. I've been bitten a couple times before by pulling drives on linux that weren't being written to, but still had a cache waiting to be written. I learned my lesson about not dismounting on an OS configuration where it isn't safe, but disabling caches is not the only way to be safe. It might take 10 seconds to flush the cache. That's okay. The key is that you never go more than a quarter second without writing to the disk until the cache is empty.
larrik 15y ago
Why? The issue is the source, not the destination. If he is getting radically different times for Network->USB vs. Harddrive->USB, then it's probably not a USB issue. As for the different OS... I mean, he isn't posting this to HN, so he may never have even used a different OS in person (most "normal" people I know haven't. Yes, including OSX).

Dylan16807 15y ago

I haven't seen a USB stick that was slower than 2-6 megabytes per second on large-file transfers. Dropping an order of magnitude of speed on smaller files is entirely windows' fault.

vetinari 15y ago
Windows uses two modes for USB devices - cached and uncached. When you plug USB stick, it is uncached by default. It was done this way, because most users do not bother with disconnecting the device and just pull the stick from USB port (and then they are surprised, that their files are not there). You can change the defaults in device properties, if you want caching on USB stick. I can show you an USB stick, that is slower than 2 MB/s. :(
- Dylan16807 15y ago
  I am aware of the distinction windows makes there. But it's artificial to make such a thing binary. If it cached but only for a fraction of a second, with queue reordering to speed things up, it would still be safe to unplug right after a copy completes.
  - vetinari 15y ago
    You can't do time-based caching like this. Block is either written, or it is not. When you flush your cache, you don't know how long it will take. Even if your cache it is only fraction of second old. That's why there used to be performance problems in apps with fsync().
    - Dylan16807 15y ago
      What I'm saying is that you make it so as soon as the light stops blinking it's safe to remove. That means that you can have a cache as long as you flush it almost immediately. I've been bitten a couple times before by pulling drives on linux that weren't being written to, but still had a cache waiting to be written. I learned my lesson about not dismounting on an OS configuration where it isn't safe, but disabling caches is not the only way to be safe. It might take 10 seconds to flush the cache. That's okay. The key is that you never go more than a quarter second without writing to the disk until the cache is empty.

larrik 15y ago

Why? The issue is the source, not the destination. If he is getting radically different times for Network->USB vs. Harddrive->USB, then it's probably not a USB issue. As for the different OS... I mean, he isn't posting this to HN, so he may never have even used a different OS in person (most "normal" people I know haven't. Yes, including OSX).