Slashdot Mirror
NAND Flash Better Than DRAM For PC Performance
Lucas123 writes "Adding NAND flash memory to a PC does more for performance than DRAM and costs less, according to a new study. As the price difference between the two memory types widens, NAND flash will become the memory of choice in the PC. The effects of NAND flash adoption are already being felt in the DRAM market, as revenue in 2011 is expected to decline 11.8%."
I work with flash daily, we make products that last 15 years with flash. Without large failure rates. The problem is not with flash. It's with the SSD implementation. It's the "let's replace harddisks with flash! and don't change anything else!" that causes problems. Because of this normal filesystems are used, that assume to be on spinning harddrives, which have no issue in writing the same sector twice, or just writing 1 sector at once. On flash on the other hand you need to do wear-leveling, and have large erase blocks. Both are handled on the SSD right now, and that's where it fucks up. It needs to maintain an internal mapping of all the flash, accounting for wear-level and shifting blocks around. One error in this internal management and your disk is junk. Even with your fancy journaling filesystem (ntfs/ext3,4/...) you are just 1 power failure away from losing your data.
Compact flash cards, SD cards, SSD, USB sticks all see this problem. So far we've only found a few suppliers of Compact flash cards which guarantee the internal management is safe, and we tested it and found it to be true. SD cards, I've a few broken "industrial grade" SD cards on my desk as proof that this is not the case. SSD is to large for our product, so I have no tests for these, but I expect the problem to be the same.
We use raw flash, with linux and JFFS2 or UBIFS. Which is a filesystem designed to run on flash, raw flash. Wake me when "SSD" offers that solution.
(TRIM is not a sollution, it's a workaround)
Compact flash cards, SD cards, SSD, USB sticks all see this problem. So far we've only found a few suppliers of Compact flash cards which guarantee the internal management is safe, and we tested it and found it to be true. SD cards, I've a few broken "industrial grade" SD cards on my desk as proof that this is not the case. SSD is to large for our product, so I have no tests for these, but I expect the problem to be the same.
If you expect SSDs to have exactly the same problems as SD cards, you're a total moron with at best shallow expertise in the field. Go look up the specs of controller ICs used in SSDs and try to tell me with a straight face that they're exactly the same thing you'd get in a SD card, or even a very good CF card.
To pick just one example, do you know of any CF cards which compress all data on the fly in order to increase effective flash lifespan by reducing the total amount of data written? (Since the SSD controllers in question use hardware compression engines which can handle hundreds of megabytes per second throughput, this also has the nice side effect of increasing effective performance, unless you're storing incompressible data.)
We use raw flash, with linux and JFFS2 or UBIFS. Which is a filesystem designed to run on flash, raw flash. Wake me when "SSD" offers that solution.
Whatever makes you think the FTL (flash translation layer) firmware inside SSDs isn't designed to run on flash, raw flash? Whatever makes you think that a generic one-size-fits-all software solution like JFFS2 applied to whatever random flash memory you put in your embedded system is better than a SSD whose firmware has been tuned for the specific flash chips it was built with? (One of the fun things about NAND flash is that it's far from generic, especially MLC, and even more especially sub-30nm MLC NAND.)
More broadly, JFFS2 is one way to skin the cat, having a "drive" abstract flash into a generic block device is another. If you want low cost, low-to-medium performance, and probably not the best possible reliability, especially for heavy write loads, JFFS2 and friends will do just fine. If you want a real HDD replacement for non-embedded-systems, it's not even close to being the right solution. Which is why you don't see anybody trying to deploy flash-managing filesystems as HDD replacements.
The controllers used in real SSDs are expensive enough that it would be a huge win if you could toss them and just use a flash FS. There are lots of very good reasons why this has not happened and will not happen. Take your head out of your butt and get some perspective, right now you're a classic example of how a little knowledge is a dangerous thing.
(TRIM is not a sollution, it's a workaround)
No, TRIM is an attempt to improve performance which has been oversold a bit in the popular computer press.
NAND flash degrades over time and has a limited amount of program/erase cycles.
Spinning rust degrades over time and has a limited amount of write/erase cycles.
Total bullshit. Please try to have a clue when you try to be clever. There is no wearout mechanism which eventually makes it impossible to alter magnetic domain orientations in spinning rust. You can keep doing that forever. In practice, the lifespan of a HDD is limited by mechanical failure or the death of the controller electronics.
The difference between NAND flash and spinning rust is that it's faster. Early evolutions of NAND flash reached the limits of their write cycles therefore. Modern evolutions of NAND flash make it more durable and reliable than spinning rust in every instance - and the speed and storage density is just a bonus.
Good god, you're clueless. Every evolution of NAND flash makes its durability and reliability worse, not better, due to some fundamental physics problems with NAND technology. The only thing keeping NAND viable is throwing ever-stronger ECC codes at the problem (decreasing the effective density gain from each process shrink by consuming more bits in error correction overhead). Write/erase cycles also keep going down, not up.
And then there's the fun phenomenon called "read disturbance". If you haven't guessed just by reading the phrase, this means you can alter the state of a bit cell in the latest and greatest generation of NAND flash by reading it (or its neighbors) too many times. Whee!
Don't confuse the application of stronger and higher overhead techniques for managing the problems with NAND with it being a super-memory with no flaws. It has a lot of issues.