The pernicious USB-stick stall problem

Posted Nov 14, 2013 19:34 UTC (Thu) by apoelstra (subscriber, #75205)
In reply to: The pernicious USB-stick stall problem by chojrak11
Parent article: The pernicious USB-stick stall problem

My understanding is that Windows basically commits everything to disk ASAP under the assumption that the user may pull the drive at any second and expect all the transferred data to be in place. (At least, all the data that the GUI says was transferred successfully.)

One result of this is that average-case data transfer on Windows is noticeably slower than on Linux, which is probably why the kernel folks are loath to copy such a solution.

The pernicious USB-stick stall problem

Posted Nov 14, 2013 19:51 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

This is classic case of "perfect is the enemy of good". Yes, Windows commits everything to USB stick right away, yes it's slow and inefficient, but it also means that you can actually use USB sticks without worry! With Linux small operations are extremely fast, but try to copy few gigs of data to USB stick and be ready to use a different computer for a few minutes (or hours) because system will be totally hosed.

The pernicious USB-stick stall problem

Posted Nov 14, 2013 21:48 UTC (Thu) by hummassa (subscriber, #307) [Link]

The problem here is "the knob works well, but the default value is not good for desktops", the solution being "when installing a desktop, remember to set the knob value to something saner" and you get the perfect case (as I have) that is fast USB copies without hogging the CPU.

Ah, and in my job I see hundreds of USB drives becoming totally hosed every year, by way users writing them on a windows machine and removing without unmounting. Don't do that, even on Windows.