The pernicious USB-stick stall problem
The pernicious USB-stick stall problem
Posted Nov 7, 2013 8:34 UTC (Thu) by nix (subscriber, #2304)Parent article: The pernicious USB-stick stall problem
But... compare it to what we have now, which is *catastrophically* wrong by default, easily giving you a situation where you can have an amount of data that can take ten minutes to write out and jamming the entire system into a stall until it's done. In order to be as bad as what we have now, a rate-estimation-based system would have to be hit with a device which goes from above-SSD speeds to USB-key speeds on the fly -- and how likely is that?
In this case, I'd say, the perfect is the enemy of the good. What we have now is bad: simpleminded rate-estimation would be better, even if not perfect. Go for that first, pile in the complexity later, and throw away those horrible old knobs. (Whichever was written to last wins?! Ugh!)
Posted Nov 7, 2013 14:48 UTC (Thu)
by jzbiciak (guest, #5246)
[Link]
I guess it depends on whether there are devices that have their own in-built caching and can absorb quite a few writes until they slow down dramatically. They could exhibit rather bimodal behavior based on the size of the incoming writes. Also, where does NFS fit in the picture? There, performance may fluctuate quite a bit as well, although I don't know if it's affected by this particular set of knobs. (Seems like it ought to be.) With NFS, you have the combined effects of the buffering on the NFS server as well as all the other people on the network vying for the same bandwidth. My gut feel tells me any simple-minded rate estimator should also have a fairly quick adaptation rate so it tracks any workload-dependent behavior and other variations in media performance. ie. it should probably represent recent history (the last several seconds), more than long-term history.
The pernicious USB-stick stall problem
a device which goes from above-SSD speeds to USB-key speeds on the fly
