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?
Enterprise storage
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.”
Monitoring Filesystem Metadata For Thin Provisioning
I began by introducing the core problem: Storage isn’t getting any cheaper due to storage utilization and provisioning problems. Thin provisioning isn’t all it’s cracked up to be, since the telephone game makes de-allocation a challenge. So now let’s talk about how to make thin provisioning actually work.
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.”
