Linus Torvalds (torvalds@linux-foundation.org) on 9/10/08 wrote:
---------------------------
>Michael S (already5chosen@yahoo.com) on 9/10/08 wrote:
>>The only case where write latency matters is a data
>>retention during sudden loss of power, but that's vendor's
>>problem, not ours. At least I hope so.
>
>See above: your buffers will fill up.
>
>And if you think a few hundred ms is unrealistic for a
>GC event, you're very naive!

Sorry Linus, but you are wrong.

To cover write *latency* you only need a few things.

1 - the ability to lie about data committed state (already common)
2 - the ability to service reads directly from the write buffer hierarchy (not difficult)
3 - the ability to BULK erase new write areas fast enough to meet your target write bandwidth (not too difficult so long as you can parallel erase blocks, and get enough power in to the device)
4 - a large enough buffer to contain enough data to cover the latency time at the given write bandwidth.

Once you have all of this, your write latency is hidden and in effect undetectible - you will be able to sustain writes at the decided write bandwidth with latency linked to your buffer, not your final storage.

This is not rocket science really, and is possible because there is not another significant requirement in flash systems that rotation disks have - the need to hard-serialise physical commits and the inevitable latency between random commits (damn that rotational latency..). Of course this is 'fixed' in disk systems with multiple separate spindles and good buffering systems, but those are not sold as 'units' generally.

So in the end we are limited by the lowest of flash parallel erase bandwidth and flash parallel write bandwidth.

Of course if this was not all true, OS caches would not work either, but they do ;)