> Another idea, Ts'o said, might be to try to write at 50% of the backing-device bandwidth, if that can be calculated, to try to ensure that there is headroom so that fsync() latency is reasonably low. One could imagine an auto-tuning process that reserved more headroom for fsync()-heavy workloads. As he noted, some of his ideas ""are in tension with one another"", so he would prefer that the heuristics used are automatic. Relying on humans to change various parameters is not a good strategy: it ""never happens"". Layton noted that reserving too much backing-device bandwidth for writes might leave too little for reads, so that is another piece of the puzzle.

Ground-breaking idea: stop the NIH and just do what zfs does. It does linear write throttling depending on the amount of dirty data, with configurable start/end points (i.e. percentage points of dirty cache size to max dirty size where throttling starts, and where writes are 100% throttled). This works swimmingly in practice, and certainly better than the current behavior of "do nothing and let the occasional slow USB stick get swamped with gigabytes of dirty data pending writeback").

Of course, there's room for improvement. If the thing could be expressed in seconds rather than bytes, it'd be even better (did anyone say "bufferbloat"?).