anon (anon@anon.com) on 9/11/08 wrote:
---------------------------
>Anonymous (no@spam.com) on 9/11/08 wrote:
>---------------------------
>>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)
>
>This conflicts with the even more fundamental requirement of having a non-broken
>system. Just because some nasty HDDs might lie about this (and maybe SSDs too, I
>don't know), that doesn't actually mean it is a solution.
>
>If you want a solution where you are happy without any data integrity, then why
>would you even bother flushing writes from the OS's caches?

Sigh, it is trivial to store enough energy in the flash unit to commit the buffers to flash on loss of power, which is what many HDDs do right now anyway, problems with that?

>>2 - the ability to service reads directly from the write buffer hierarchy (not difficult)
>
>Why would you need this? The OS already has that data cached so reads will be serviced
>from there. The only way this would even do anything is if you have multiple processes
>performing direct-IO on the same blocks. But similarly to the OS, something like
>a database would not do such a thing, and if you have two non-cooperating processes
>doing IO to the same blocks, something is likely screwed up anyway.

So, what exactly do you do with situations where the OS does NOT do that? (ie: anythgin useing direct disk access APIs?) fall over flat on your face?

>Are you just making up these requirements off the top of you head? Or do you have some in depth knowledge of the area?

Quite a bit more than you it seems.

I did forget one other though.
The use of flash devices that support overlapped erase and read (preferably also erase/read/write) - this of course has been common for decades for the purpose of microcontrollers that support code execution from the same device being used for storage (its a good idea for your code store to keep working during an erase cycle ;) ).

Flash devices (by which I mean the actual storage chips..) will undergo quite a rapid set of modifications to bring them more inline with fast storage requirements should the market grow suitably - none of these changes are difficult, and intel has already started to show the way.

The problem is historically most large capacity flash uses are not highly random-access or high performance, so the chips used are quite 'simple', this is not the case for all flash devices.

Anyway, all those problems are easy to solve, the big one that ends up standing out is the power requirement for fast sustained erase - fast flash drives could quickly use more energy than disk media, but in doing so may deliver much higher performance. I predict flash drives with cooling fins, perhaps even fans, in the moderate future.