Solid State Disks - Level 5 cache
Last month I had the pleasure to spend 2 hours in the car with Klaus Grieger. Klaus and myself know each other from ObjectDesign and Versant. Right now he is a partner with CIMT AG in Germany. As always talking to him was invigorating. He is one of the most innovative people I know.
The topic of the drive was the future of Solid State Disks (SSDs). His thought was/is that with the arrival of in-expensive, fast SSDs we can potentially rethink the way we structure memory and storage in general. Right now, we "load" executables from a "disk" into "main memory". What if, we turn the disk into a level 5 CPU cache, means programs never get loaded and/or started. They get installed into "memory" and will stay there all the time. Instructions get fetched into lower-level CPU caches on as needed basis. This would/could probably work for instructions, but not for data. Means for data you would still needs a disk with a file-system.
Hhhhmmmmmm, ... can somebody help me to think this through?
The topic of the drive was the future of Solid State Disks (SSDs). His thought was/is that with the arrival of in-expensive, fast SSDs we can potentially rethink the way we structure memory and storage in general. Right now, we "load" executables from a "disk" into "main memory". What if, we turn the disk into a level 5 CPU cache, means programs never get loaded and/or started. They get installed into "memory" and will stay there all the time. Instructions get fetched into lower-level CPU caches on as needed basis. This would/could probably work for instructions, but not for data. Means for data you would still needs a disk with a file-system.
Hhhhmmmmmm, ... can somebody help me to think this through?
posted by Roland Tritschat
13:25
1 Comments:
I am very sure that the last sentence of the first paragraph about Klaus is not true ;-)
About solid state disks: I think, this should even work for data. Handspring (now Palm) brought this innovation several years ago with the Treo 650. I think it was the first PDA that did not loose any data when it runs out of batteries. The Treo transparently loads a memory page from non volatile memory into volatile memory when the application accesses the data. Later, it is written back into non volatile memory.
See NVFS
Why would an application want to access its data via a file-system-API that is built on top of a random access (non-volatile) memory?
Why would someone want to manage access paths to application data using something like FAT32 or NTFS emulated on (non volatile) RAM?
Those file-based APIs are used because block-I/O is the only operation a hard disk can do and a sequential stream of bytes is the only abstraction that is really supported.
Whenever an application starts it needs to read the files and transform data from disk optimized block structures or bytes streams into processing optimized structures (e.g. java objects with wild pointers between them).
At the end, the file needs to be written back.
It's ok, as long as you have block-oriented devices. But now, it is all random access memory.
But using non-volatile memory like RAM is not so easy. To keep data consistent, it must be written back to non volatile memory in a controlled way. In case of an application exception, we do not want to have all pointered data structures messed up.
The Treo solved this problem in a simple way - sufficient for the PalmOS applications.
In general, it would be good to allow the application to call "transaction commit" to let the OS write back all modified bytes into non volatile memory in an atomic way at the right point in time.
Since all applications use file-system APIs (or database APIs) today, it can only be a long conversion path with more and more applications taking advantage of solid state disks in a smarter way. At this time, the partition of the solid state disk that does not have a file system layout will certainly not be called "solid state DISK".
Klaus
Post a Comment
Links to this post:
Create a Link
<< Home