Many years ago I studied electrical engineering. I was an awful at it. Analog was never my thing. I much prefer ones and zeroes. But I challenge myself to think about electronics once every blue moon. So I decided to delve into SLC and MLC flash technologies to understand how they differ and why we should care.  The content below summarizes my online research and the little bit I remember from school. If you can add, correct, or update this article I would be happy to have your comments.

What is the Difference Between MLC and SLC Flash?

MLC flash uses many discrete voltage levels to store multiple values, or bits, per cell [1].  Single-layer Cell (SLC) technology uses fewer voltage levels to program a single bit of information to the cell.  MLC technology obviously produces greater density which means it stores more data cheaper.  But the higher density comes with a cost: MLC produces storage that is more sensitive to temperature changes, slightly slower, and more likely to fail than SLC flash.

SLC flash is ten times the endurance for write/erase operations [2].  At an average of 10,000 write/erase cycles an MLC flash cell will die.  SLC flash cells can sustain an average of 100,000 write/erase cycles.  But why do MLC flash cells fail more than SLC?

Why Do MLC Cells Fail More Than SLC Cells?

I am unable to find an answer to this anywhere on the web.  If you see one, I would love to read it.  But in the dark, dusty corners of my memory I remember enough about electronics to hazard a guess at this.  As I see it, there are two reasons why MCL flash should fail more than SLC: one reason is a statistical and the other is electronic.

The statistical argument is that MLC cells are being written two 50% more than SLC cells.  They will simply wear out sooner. An SLC cell is storing the value of zero or one.  When an application writes to the data being held by that cell there is a 50% chance that the cell’s value has changed and it requires reprogramming.  Because MLC flash stores two bits, there is a 75% chance that the new two-bit data differs from the existing value.  This means an MLC is written to 0.75 times for each 0.5 times an SLC cell is written. That’s a 50% increase.

The electronic argument is based on MLC flash programming requiring a wider range of voltages [3].  Higher voltages produce greater amperage.  This exacerbates electromagnetic migration.  And the higher voltage on the transistor’s gate will increase erosion of the polysilicon that separates the gate and the channel.  Both of these will result in circuit failure.

How Is MLC Being Made More Reliable?

Because MLC is so much more cost effective than SLC, industry innovation is improving MLC reliability.  Here are a few techniques I found online [4]:

• Hardware can level writes, which distributes writes throughout the device to avoid balance cell overuse and avoid hotspots.  This means an entire flash drive will tend to fail at once after a long time.  This as opposed to a small number overworked hotspots failing quickly.
• Hardware can include DRAM cache which can be used to coalesce writes, which decreases cell write count.
• Flash devices can be over-provisioned for error detection, correction, and dynamic bad cell replacement.
• There are also a variety of proprietary techniques from flash manufacturers.

One challenge with flash today is the lack of consistent and objective endurance measurements.  It is difficult for storage vendors to publish availability guarantees when the reliability of the underlying media is uncertain.  This means to support flash devices in its VMAX arrays–which are rated at six nines (99.9999%) availability–EMC has to do a tremendous amount of qualification of the devices. This qualification process should always mean that flash support in enterprise storage should consistently lag its support in consumer devices, where availability requirements are much lower.

Summary

No one denies that SSD storage is becoming more common in the enterprise. EMC’s support of MLC devices is only one of the items introduced by Project Lighting that will increase flash presence, producing better performing and more efficient storage. If you are interesting in learning more on the subject, follow the links below to the sources for this article. Also considering Googling “tlc flash” to see the higher density, less reliable Triple-layer Cell (TLC) that will certainly find its way to the enterprise after more innovation.

References

My information came from documents I found as a result of Google searches. Here are my recommendations for further reading.

1. http://www.smxrtos.com/articles/mlcslc.htm
2. http://www2.electronicproducts.com/Choosing_flash_memory-article-toshiba-apr2004-html.aspx
3. http://www.supertalent.com/datasheets/SLC_vs_MLC%20whitepaper.pdf
4. http://www.infostor.com/index/articles/display/1169849064/articles/infostor/disk-arrays/disk-drives/2010/july-2010/mlc-vs__slc_flash.html

In 2009 VPACT paper, VMware engineers showed application performance when the storage is consolidated.  This paper is a bit academic for the average virtualization nut, but does contain insights into choosing which VMDKs to consolidate into a single VMFS volume.  It does this by running applications that contain random or sequential IO and comparing performance with isolated (dedicated) storage to performance using consolidated storage.

The first experiment tested DVD store against Microsoft SQL Server and Oracle Swingbench OLTP against an Oracle database.  These OLTP workloads result in random IO on the data disks.  In the isolation experiment each virtual machine was run with its VMDK on a three-disk RAID 5 LUN (2+1).  In the consolidation experiment, both virtual machines’ VMDKs were put on a common six-disk RAID 5 LUN (5+1).  Here are the paper’s results from table 1 of the paper:

Consolidating Random Access Virtual Disks

The “application metric”, transactions per minute, is the most important indicator of the end user’s observed performance.  You can see from the results that consolidating (sharing) storage of random workloads does not harm performance at all.  In fact, SQL Server performance increased by 25%, reflecting the relative increase in data disks per stripe.

The second experiment again used DVD Store against SQL Server for a random IO workload.  But instead of a second random workload, an Oracle database was tested by the Swingbench Decision Support System, which results in highly sequential access.  Here are the results of that experiment, taken from table 2 of the paper:

Sequential Workload Consolidation

The random workload, SQL plus DVD Store, again improved as the relative percentage of data disks in the RAID volume increased.  But the Decision Support System workload, so heavily dependent on sequential storage performance, suffered greatly.  DSS performance dropped 30% when measured by IO throughput and 50% when measured by completed transactions.

Applications with a sequential storage access pattern can be heavily dependent on the array’s ability to coalesce IO requests and complete large numbers of IOs very rapidly.  But when a VI admin includes a random access VMDK on the same LUN, the aggregate, interleaved LUN access is no longer sequential.  This slows down the array’s sequential and its effects are profound at the application level.

There are two summary recommendations from this experiment:

• A smaller number of RAID 5 volumes using many disks will outperform a larger number of RAID 5 volumes that use fewer disks.  This is due to the relative decrease in parity on the configuration.
• VMDKs with random access can be consolidated to a single VMFS volume safely but sequential access pattern files should be separated to their own LUNs.

The VMware performance team has a lot more to say about storage design to maximize application performance in virtual environments.  I will have more blog articles as the weeks progress and a white paper to share in the second quarter of 2010.  I expect it to be ready no later than EMC World 2010.