Linked by Thom Holwerda on Sun 14th Apr 2013 20:30 UTC
Hardware, Embedded Systems "In the past five years, flash memory has progressed from a promising accelerator, whose place in the data center was still uncertain, to an established enterprise component for storing performance-critical data. It's rise to prominence followed its proliferation in the consumer world and the volume economics that followed. With SSDs, flash arrived in a form optimized for compatibility - just replace a hard drive with an SSD for radically better performance. But the properties of the NAND flash memory used by SSDs differ significantly from those of the magnetic media in the hard drives they often displace. While SSDs have become more pervasive in a variety of uses, the industry has only just started to design storage systems that embrace the nuances of flash memory. As it escapes the confines of compatibility, significant improvements in performance, reliability, and cost are possible."
Permalink for comment 558557
To read all comments associated with this story, please click here.
RE[2]: Comment by TempleOS
by Neolander on Mon 15th Apr 2013 16:08 UTC in reply to "RE: Comment by TempleOS"
Member since:

Oh, there's something I missed this morning too...

Why would we go from volatile to non-volatile?

I'd say the main reason for doing that would be increased reliability and simplified abstractions.

Reliability would be increased because machines could be smoothly powered off and back without losing any state, and without a need for hackish "save RAM data to disk periodically" mechanisms. Suspend and hibernate could well cease to exist in less than a decade, replaced by the superior alternative of simply turning hardware on and off by flipping an hardware switch.

Abstractions would be simplified because there wouldn't be a need to maintain two separate mechanisms to handle application states and data storage and interchange through file. A well-designed filesystem could instead address the use cases of both malloc() and today's filesystem calls, much to the delight of "everything is a file" freaks from the UNIX world ;)

(As an aside, the latter could actually already be done today, by allocating all free RAM into a giant ramdisk, mounting it alongside mass storage, and treating process address spaces as a bunch of memory mapped files. It simply doesn't make sense at this point, since both memories have such different characteristics...)

Edited 2013-04-15 16:21 UTC

Reply Parent Score: 3