October 20, 2014

The Bridge: Veritas Thin (Provisioning) API

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!

Thin provisioning needs communication to function, and zero page reclaim is only the array side of the story. WRITE_SAME helps reduce I/O load, but the server needs to use it. Wouldn’t it be nice if the operating system, file system, or volume manager would use these commands to help recover capacity?

We need a bridge. We need to cross the gulf between the storage array (that expects all these zeros or some other way to recover this space), and the host (who has this information)

That’s the thing that gets me riled up. The application and the file system know that this data is no longer used. If there was only some way, some bridge, that allowed them to talk to the storage array and say, “Hey, you can get rid of that now. I don’t need it anymore.” See? We need a bridge.

Well, guess what? We have some bridges. One of my favorite developments in storage of the last year is this Thin Reclamation API that Symantec has. I really like what they’re doing.

Symantec (formerly Veritas) have the file system and the volume manager. If you’re an enterprise guy like me (I was using HP-UX in 1996) you have used the Veritas File System and Veritas Volume Manager before.

Symantec calls all this Veritas Storage Foundation now. It has the information thin provisioning storage arrays need, and they’ve come up with a way to communicate: Being a software company, Symantec implemented just about every communication method, because not everybody uses this WRITE_SAME, and not everybody uses zero page reclaim. Some of them have their own API for recovery. So Symantec tried to implement as many thin methods as they possibly could right in the file system and volume manager.

I’ve talked to a lot of people who are using it, and they say that it works. They say that it’s brilliant. Because you turn on this feature and, suddenly, the file system starts telling the array “I don’t need this data anymore.” Suddenly one of my major complaints about thin provisioning goes away.

But I have a question: Why doesn’t everybody do this? Why isn’t this in the Linux file systems and volume managers? Why isn’t Microsoft working on this? Why doesn’t everybody have this capability? It’s not rocket science. It just takes a little bit of development effort to try to come up with some kind of way to have the file systems talk.

  • http://thestorageanarchist.com the storage anarchist

    Whew! Cliffhanger averted.

    Since you created this presentation, we now know that both Linux and Windows Server will support SCSI UNMAP…much as they both already support the SATA TRIM command.