May 19, 2012

What is WRITE_SAME? Green Eggs and Ham!

One of the sticky wickets that holds back thin provisioning is the need to communicate when capacity is no longer needed. Enterprise storage arrays can reclaim zeroed pages, but writing all those zeros can really fill up an I/O queue. This is where WRITE_SAME comes into the picture.

Zero Page Reclaim: Savior of Thin Provisioning?

On the storage side, arrays can only use the information they have to deallocate: The data that’s stored on them. They don’t know what application is using it, what file system it is. But, somewhere along the line, someone had a big idea and said, “wait a second, what if we look for pages that are all zeros?” We’ll talk about pages a bit later, but for now, let’s talk about zeros. A zero is kind of a smoke signal coming up from over the hills that says, “there’s nothing valuable here.”

Thin Provisioning: Playing the Telephone Game

What happens in the telephone game is that a little bit of information gets lost at each step along the path, and at the end of the chain you’ve basically lost all the information. And this happens all the time in computers, especially in data storage. Thin reclamation is the core technical challenge to thin provisioning, and the telephone game is the reason.

De-Allocating is the Core Issue for Thin Provisioning

One of the biggest problems for thin provisioning is not the provisioning part: It’s fairly easy for a storage array to allocate on request: “I need a block; here’s some data I want you to write.” And the storage array just starts allocating, and allocating. But, the operating system never goes back and says “I don’t need that block anymore.”

Thin Provisioning: Attacking Storage Utilization

Thin provisioning doesn’t take on the cost of capacity, it actually attacks the overhead of inefficient provisioning. Not all of that overhead is inefficiency, and not all of that can be tackled with thin provisioning. But some of it can. It’s a lot more of the cost than can be tackled by moving to SATA, for example. That I really like.

Storage is Not Getting Cheaper

Slide25

Why do we care about thin provisioning? Because storage is not getting cheaper. If you went to buy a disk ten years ago, you’re going to spend about the same as would today, but you’re going to get a lot more capacity – a lot more capacity! The fact that we have terrible utilization of enterprise resources is really not helping us, and it’s not getting any better. It hasn’t improved because they are “doing storage” the same way.

Back From the Pile: Interesting Links, November 26, 2010

Oops! This never got posted, what with Thanksgiving and all. So, one week delayed, here are my interesting links from a few weeks back!

Overcoming The Limits Of Thin Provisioning With Automatic Provisioning!

Most thin provisioning solutions are colossal hack jobs. How about real automatic provisioning instead?

I’ve never been a fan of thin provisioning as a storage management tool. Don’t get me wrong, I love having thin provisioning in my toolkit to overcome the limitations of conventional filesystems. Thin provisioning just gets under my skin when folks try to use it to solve business problems like long deployment time and slow purchasing cycles. If you attended any of the thin provisioning sessions I’ve presented at Storage Decisions, Interop, E-Storm, or elsewhere then you’ve heard my wistful dreaming of real automatic provisioning without the hackery of thin provisioning systems. But perhaps I didn’t mention that actual automatic provisioning actually exists today! It’s one of the many things I love about API-driven cloud storage!

Use Process Solutions For Process Problems, Technical Solutions For Technical Ones

If there is a universal best practice, it’s the simple idiom, “use the right tool for every job”. We in IT spend so much time trying to fit square pegs into round holes, it becomes second nature. But the time has come to adopt a new best practice: Use process solutions to solve process problems, and technical solutions to solve technical ones.