Pliant’s Greg Goelz is currently featured on the storage site, STORAGEsearch.com.  In the article, Greg shares his list of recommended articles and resources about SSD market trends and technologies.

Check it out!

Amyl Ahola

A recent article by editor Zsolt Kerekes of STORAGEsearch.com entitled, “flash SSD Jargon Explained,” got my attention.  The fact that there is a need to explain the jargon is a reminder that the marketing wizards keep inventing new terms to ‘differentiate’ their products, while confusing most of us and masking issues of real importance to data center operations.   A version of marketing 101: If you have a weakness, flaunt it.

The list of SSD jargon Kerekes cites in the article includes: dynamic leveling, active leveling, static leveling, BCH codes, Reed Solomon codes, write endurance, write amplification, write attenuation, garbage collection, read patrol, wear leveling, read disturb, and program disturb.

Look at the last two.  These are rarely discussed but are among the most important issues to those who care about losing data.  An earlier STORAGEsearch.com article asks the question, “Can you trust your flash SSD specs & Benchmarks?”  The answer can only be ‘of course not!’  At least not until there is some semblance of standardization.  This is especially true when considering using SSDs to meet the performance and reliability demands of enterprise applications.

With this in mind, some questions that should be asked (and answered) about SSD performance and reliability specs and benchmarks are:

1.    What is the real performance?

A simple question but rarely, if ever, addressed in the specifications.  Typical environments are random, 60%-70% read, and 4K/8K blocks.  Not small blocks (512b) to show high IOPs, or large blocks to show high bandwidth.

2.    Is the performance deterministic?

The writing process for flash is inherently slower than reading.  Does the performance drop substantially as a function of the read/write mix or does it stay relatively constant as needed to maintain consistent response times?  Is the performance dependent upon the use of cache (and the associated power loss and recovery issues of volatile cache memory)?

3.    Is the performance sustainable?

What does ‘sustainable’ mean? It is not unusual for performance to degrade as more and more of the device gets written to…it may take minutes or hours, but degradation of 50% or more may occur.

4.    What is the capacity available to the user?

Another simple question, but all SSDs contain more flash than that available for end user data. For example, the additional (or over-provisioned) flash may be used to optimize write performance, provide for spare blocks, CRC codes, ECC codes, and meta data.  Does the stated capacity net this all out?

5.    Are there duty cycle or other limitations on usage in order to achieve/maintain the specifications?

Does the architecture provide for 100% duty cycle, or is the product life contingent on a maximum number of writes or writes per day due to limited error management capability.

Is it assumed there will be ‘adequate’ idle time (what’s that in the enterprise?) to perform the necessary flash management activities?

6.    Are the error management and ECC algorithms powerful enough to correct read disturb and program disturb errors without resulting in excessive rates of uncorrectable errors and/or losing capacity due to bad block mapping?

Error correction approaches which utilize limited ECC to correct random bit failures may not have sufficient correction capability for read/program disturb errors. Correction capabilities may appear adequate but be based on codes, such as the Reed Solomon code, which is great for hard drives but not really applicable to flash failure modes. The lack of idle time for background flash management makes this problematic for many / most SSD architectures.

Kerekes sums it up well: “Better user education about SSDs is a critical factor for the industry to sustain its growth. Design trade offs in products go far deeper than the choice of memory and interface. Being aware that there are other parameters which SSD vendors have implemented well, badly (or not at all) can be the difference between a satisfactory or disillusionary experience.”

What do you think?

Amyl Ahola