How would you classify IBM’s XIV? It seems to be somewhere in between “nice” and “saintly.” Zero page reclaim is a scheduled process (manual, but automated) which runs, by default, once a day. My understanding though, is that it can be scheduled to run much more frequently if needed…

Additional Notes from Tech Field Day by VMwareInfo.com…

Aren’t there two other important elements with thin provisioning implementations?

The first is whether a storage system’s implementation of thin provisioning requires manual pre-allocation of storage capacity from free space into pools or aggregates of a specific RAID type, before the thin provisioning can work? I think EMC, HDS, NetApp and IBM’s XIV TP implementations all do this. This means that cookies get grabbed by the storage array up front before any application data is written. Now that’s a Glutton of a Cookie Monster personality – grabbing more than they need up front (even if they actually use some of the “pool” Cookie over time, it’s really not that different from a Greedy Cookie Monster’s approach of early allocation into “volumes”).

The second, is how much the storage system allocates to an incoming write – the allocation unit size for its thin provisioning implementation? With EMC it a huge 768KB for even just a 4K write. With HDS it is a whopping 42MB. When some file systems initially lay out their metadata periodically along the volume (every few MBs), the storage system ends up allocating huge amounts of storage capacity before ANY application data is written. It’s as if the storage system grabbed a super-sized cookie, when it only needed to grab a mini cookie. Just another case of grotesque gluttony.

The important implication of this is that you could eventually have arrays that claim to be Saintly Cookie Monsters under your definition above, who really are just Gluttons all the same, because of their inefficient implementations. 3PAR makes a big deal of the fact that they are a Saintly Cookie Monster without these Gluttonous side-traits.

Sadly you still celebrate the Monster. Writing zeroes in all those blocks is inherently IO inefficient, which is why most systems did not do that, preferring to do logical deletes. The Zero filling approach is a typical reverse engineering workaround – much marketed at the moment.
I recomend you acknowledge the ‘Elegant Solution’ formerley known as the Monster (with apologies to Prince).
I can confirm that there is currently such a solution in existence (with limitations – it does not do ALL filesystems but definitely does NTFS and NFS today).
You have my EMail if you want to query

i think this a catchy analogy. Good write. I’ll add some “cookie-guessing”.
It might be a good idea to write a post listing all the arrays out there and provide a cookie scale to it. From greedy to saintly with their corresponding code levels. Like IBM SVC code lower then 4.3 would be greedy, 4.3 to 5.0 would be selfish and 5.1 and up code is a saintly cookie monster.

Just an idea.

Cheers