March 3, 2015

Is TRIM Useful For Thin Provisioning?

State of the Art Thin Provisioning Series

One of the topics I've often written and spoken about is thin provisioning. This series of 11 articles is an edited version of my thin provisioning presentation from Interop New York 2010. I hope you enjoy it!

If WRITE_SAME can be a semaphore for thin un-provisioning, what about TRIM? It sounds like a perfect fit, and has wider implementation to boot! Let’s take a deeper look.

First, I’d like to remind the reader that I’m not some specialist storage engineer. I am regular guy who wanted to know about this TRIM thing. I welcome corrections and feedback on this piece!

We should note that TRIM was invented for SSDs, not thin provisioning. TRIM lets an operating system tell a storage device that certain blocks of data are no longer used. Although this sounds like a thin provisioning tool, it’s not. TRIM was never intended to be used this way.

Even though Microsoft supports TRIM in the file system, and even though, hopefully, Apple will introduce TRIM support in OS X Lion, this doesn’t do what we need it to do for thin provisioning. In fact, TRIM is not anything for enterprise storage folks to be getting all that excited about.

One reason for is is that TRIM is an ATA command, and most enterprise systems are not connected to their storage using any kind of ATA-based protocol. Maybe there are SATA disks somewhere down the line, but, whether they use iSCSI, FC, SAS, or FCoE, the servers speak SCSI.

Even though there are SCSI analogs of of TRIM, these commands were really not designed for thin provisioning. They are designed for SSDs, which have a big performance problem: An SSD can delete data and write data just fine, but in order to update data, they actually have to read, delete, and write a big page of data. What happen is that, as an SSD gets full, it starts slowing down. And that’s a problem because people buy SSDs for speed. So TRIM is a way to tell the SSD, “Sometime in the future, you can go ahead and delete this if you feel like it,” and the SSD will take care of that later.

There’s great OS support for this, but unfortunately, this is not something that enterprise storage vendors are looking at. The only vendor (that I know of) that’s working on this, NetApp, did propose to T10 a mechanism to do thin provisioning based on TRIM. I don’t think it got anywhere. They say that it did, but I just don’t see it. HDS and EMC, seem to like UNMAP and SCSI, which are peripherally related, but I don’t know much about what they’re doing either. Perhaps they’ll let me know in comments on this post.

  • the storage anarchist

    I wrote about the SCSI UNMAP and WRITE_SAME(UNMAP) commands here:

    Enginuity 5875, shipping since December for VMAX, supports both new SCSI commands, for both thin devices AND for thick ones (read the article to understand why).

    FYI – while TRIM was originally created for SATA-based Flash drives, it turns out that the SCSI commands were actually in development for Thin devices even *before* Flash drives hit it big in the SCSI world. Both Symantec and EMC (among many others) contributed to the development of these new space reclamation APIs – for both thin AND Flash devices.

  • Hu Yoshida

    I agree with Barry’s description on the use of Write Same and UNMAP SCSI Commands. Every vendor will eventually implement support for these commands as they provide enhancements to thin provisioning capabilities. We currently support Write Same with and without the UNMAP bit in the AMS and USPV storage system platforms. Our new VSP product will have them very shortly as we finish testing. We are also providing support for the UNMAP command this year. The implementation of Write Same and UNMAP requires hosts to issue these capacity reclamation oriented commands. The AMS, USPV, and VSP provide the necessary SCSI level changes for applications to become thin provisioning aware so as to seamlessly implement these enhancements.

    One difference in our VSP and USP V products from competitive products is that we will also reclaim space on external storage that is virtualized behind the USP V and VSP. Once storage is virtualized we can move a volume into a Dynamic Provisioning pool and then using Zero Page Reclaim immediately free pages that contain zero format data (unused space) and return them for reuse in the HDP pool. Additionally, the external storage as part of the HDP pool can have storage reclaimed by being released using the Write Same command or the UNMAP command. So if your storage does not have the thin provisioning capability and still has some residual value, virtualize it behind the USP V or VSP and extend its capabilities with thin provisioning and Zero Page reclaim.

  • sfoskett

    Thanks for this additional information, Hu!

    I need to learn more about UNMAP next. I’m just trying to find my way through all this, and I appreciate the help from you, Barry, Mark, and the rest!