Fusion-io is wooing programmers with a software development kit loaded with interfaces so apps can directly access a flash cache as a memory tier. Fusion-io ioMemory OS subsystem technologies like Auto Commit Memory and Atomic Writes, which were used in the billion IOPS demo, are available through the SDK. Developers can use the …
Ok, there probably is a way to back up memory. Probably.
Yay, this is what we need... hardware specific applications! It's all fun and games until your disk provider goes out of business or is bought by a competitor or loses interest in the product or...
Those levels of indirection are there for a reason. Unless you have short application and hardware lives, this is madness.
Re: WTB... Backups
Not to mention that having applications poking their grubby fingers around in the flash cache directly without the OS knowing about it is all going to end in tears when the data corruption fairies notice.
Programs that bypass the authority of the Supervisor program? They'll be driving around the system on stolen lightcycles next, mark my words......
I would be more impressed...
I have a suspicion that this could all have been achieved in a more flexible, transparent and portable manner by using mmap()... If you want to avoid memory-to-memory copies you could stuff NV memory into DIMM slots and use a kernel space RAM disk. We've got 64 bit address spaces now so having the kernel consume a few GB for a ramdisk isn't going to hurt as much as it used to. This isn't hard Mr.Vendor, get the funt on with it.
Re: I would be more impressed...
This is what I've assumed makes the most sense too. Specialized APIs are scary because they have unpredictable behavior, complexity, slow bug resolution, and tech lock-in. Have 128GB SDRAM and 20TB Flash as swap. Now the apps can do what they need to do and let the OS worry about the most efficient way to handle memory. Flash card makers can make their money selling highly optimized virtual memory implementations.
Back to DOS then
I am sure there was a reason why we moved away from having direct hardware access in the past!
Oh yes, reliability, oh and security, oh and portability, oh and ... you get the picture.
One step backwards?
This API will be a vendor lockdown. Without going through the OS you lose the generic interface in favor of the hardware specific. Kind of like what the world was before SASI.
Recipe for disaster
Hmm an app that can write to memory that the OS has no control over? What possible harm could malware writers cause with this. What's going to stop a rogue app writing over any memory it likes if the OS can't stop it. This is why the win 9x line was killed off, is the OS overhead really that bad? It's not worth the speed against the damage done.
Were are getting a compact little monster for giga-pixel and later tera-pixel image processing coming Monday: 64 cores, 512 GB RAM, 6 1TB disks in RAID, and a 320 GB Fusion-IO card. I do not think I will let my students loose on this API just yet. First let them code in a transparent portable way, and only then (maybe, just maybe) check whether this API has any benefit (which I doubt).
The future of so-called "IO-bound applications" is already here and it is called "database-in-memory". Flash-hypesters like Fusion-IO love to endlessly misquote Jim Gray, like this:
"Tape is dead, Disk is Tape, Flash is Disk!"
What Jim Gray actually said is:
"Tape is dead, Disk is Tape, Flash is Disk, and RAM locality is King"
I doubt there will be a single major application vendor (or even a decent tier-2 vendor) that will ever write to this thing. It's just plain goofy.
- Hi-torque tank engines: EXTREME car hacking with The Register
- Review What's MISSING on Amazon Fire Phone... and why it WON'T set the world alight
- Product round-up Trousers down for six of the best affordable Androids
- Antique Code Show World of Warcraft then and now: From Orcs and Humans to Warlords of Draenor
- Why did it take antivirus giants YEARS to drill into super-scary Regin? Symantec responds...