Inside IT Storage

Seagate Enterprise Inside IT Storage

MLC enables enterprises without breaking the bank

Back in May, I presented the blog and question, “Is MLC the future of enterprise SSD storage?” and covered the ground with a discussion of the current standards, trends, and thoughts from analysts. It became clear that Multi-Level Cell (MLC) technology used within Solid State Drives was going to remain an important part of enterprise storage deployment.

And now CTOEdge has recently published, “Six Steps for Making MLC Work in the Enterprise”, an extensive piece that updates and expands on these areas. Written by Seagate’s Teresa Worth, the story presents a unique inside-perspective on the obstacles surrounding SSD adoption, provides an update on standards body works, and shares ways to simplify SSD adoption and deployment.

IT pros are always looking for ways to improve the performance of their storage infrastructure as their data-intensive applications needs grow. SSDs show promise to fulfill these needs, but still also have their range of challenges for deployment. And certainly MLC technology, as Worth adds in her story, can help successfully incorporate SSDs into data centers without breaking the bank.

Check out the CTOEdge piece about the methods and best practices for deployment and do let us know your thoughts.

Have you deployed SSDs at your business or are you still waiting? What issues have you experienced or what concerns do you have?

2 Comments

  • Richard Reynolds Says:

    I was involved with Enterprise Storage solutions for Telco for many years and would not recommend MLC NAND-based SSDs or modules. Many customers were requesting SSDs and also would not allow MLC NAND. I and many familiar with the industry do not feel that Enterprise storage implying mission critical data can use MLC technology. There were many attempts by suppliers to convince me that MLC technology was appropriate with the use of over-provisioning, wear-leveling algorithms, write amplification, etc. In terms of cost, eMLC made no sense either, especially when considered a compromise to SLC. An eMLC-based SSD required over-provisioning by >100% to achieve the same endurance as SLC. This actually resulted in spending more for the same device comprised of <50% SLC capacity. Also, MLC write performance cannot match SLC. So, why bother? I think the move to MLC is strictly being promoted (forced) by the flash manufacturers who's goal is always the same, getting more capacity yield for their silicon, not unlike the DRAM business.

    In conclusion, I think MLC has it's place, if the user is fortunate enough to be able to characterize the end-usage application to be appropriate to meet the required service life. But, SLC NAND will be the only choice for true Enterprise data applications and therefore, will be around for many more years.

  • We definitely appreciate your comments. Fortunately, not all MLC NAND is the same, and there are numerous grades of it. Longer story short, enterprise-class MLC is quite different than that used for consumer-grade devices.

    Also, there have been advances made with garbage collection and other areas of managing the flash itself throughout its life cycle, which also now makes MLC-based SSDs a suitable choice for enterprises. We should certainly do an updated blog post in this area to provide the details.

    David Szabados

Post a Comment

Your email is never shared.

* Required fields

* Seagate will review all blog submissions and determine, in its sole discretion, whether such submissions will be posted for broader viewing. No blog comment will be considered for posting if deemed potentially damaging to Seagate's reputation or insufficiently aligned with the relevant blog topic. Without in any way limiting the foregoing, no submissions will be posted that contain: confidential company information; profanity; racial slurs; gratuitous references to sex, substance use, or violence; or statements that are in any way contrary to the letter or spirit of Seagate's Code of Business Conduct and Ethics.