Home | GestaltIT | Enterprise Computing: Thin Provisioning and The Cookie Monster!

Enterprise Computing: Thin Provisioning and The Cookie Monster!

0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×

The Gestalt IT Field Day was a great success in bringing together a mixture of delegates from varying discplines. Following the presentations from 3Par and Symantec, there was heated debate about the implementation of Thin Provisioning and the ability to reclaim released storage resources. This post covers the basic concepts of Thin Provisioning and more importantly how deleted resources can be recovered over time.

Thin Provisioning Primer

The underlying concept of thin provisioning is pretty simple; provide storage resources to those requesting it only as they need it.

Think of a standard ‘thick provisioned’ environment.  As thick LUNs are created, the storage is assigned and mapped to that LUN to the full extent of the size requested.  See, the first graphic, which shows a RAID group of four 5GB drives.  I’ve assumed “RAID-0″ here for simplification, i.e. no RAID overhead.  Each LUN (coloured separately) is made up from a 1GB slice of the available disks.  Thick provisioning is great if the LUNs are all 100% allocated.  In that instance, 100% of the available physical space is used up.  However, it is never the case that 100% of a LUN is used and so wastage exists. 

Look at the second graphic.  This shows how thin provisioned LUNs work.  As storage is requested by the LUN, the space is mapped to physical blocks of storage.  In this example, none of the logical LUNs are fully utilised and so don’t consume their full theoretical capacity.  This means that the pool of space can be over-subscribed and a sixth new LUN created.  Obviously there’s no such thing as a free lunch or infinite storage resources and in this example if a further five blocks are requested then physical space would be exhausted.  The next request for a new storage block would result in an error situation and this represents the main concern with over-subscribing thin provisioned volumes.

Now we get the concept of thin provisioning, there are a further two aspects to consider.  Firstly, when we say a LUN isn’t 100% utilised, what to we mean?  Second, how can deleted blocks be returned to our free physical pool?

As LUNs are presented to hosts, they are formatted with a file system, for example on Windows it’s NTFS; a VMware environment would use VMFS.  The file system will have a standard layout which determines where the file index sits and the method in which files are allocated onto the disk.  Have a look at the third graphic.  This is a map of the C: drive for one of my servers.  Each block represents approximately 22MB.  You can clearly see the MFT (NTFS index) in the centre of the volume.  A large percentage of the disk is unused.  In a thin provisioned environment, storage would have been requested only for the blocks with valid data and in this way, a LUN can be less than 100% allocated. 

OK, so what happens if I create some files then delete them on the file system?  Most file systems remove a file by deleting the entry in the index rather than physically overwriting the file contents with binary zeros.  This is quick and efficient (if not slightly unsafe security wise).  The actual data isn’t overwritten and it is this ‘logical’ deletion that enables undelete utilities to work.  The trouble is, most disk arrays are not file system aware and so can’t detect the logical deletion of a file.  Those arrays that offer thin provisioning typically detect unwanted space by looking for blocks containing only ‘binary zeros’.  This means simply deleting files will not release unused space back to the free block pool (except for one storage device I’ll discuss in more detail another time, that’s Drobo). Arrays which are capable of recovering unused space need to see data overwritten in order to recover it.

This (finally) brings us to the cookie analogy.  Imagine cookies are my free pool blocks.  There are a number of ways in which storage arrays operate in handling thin provisioning – different cookie monster personalities:

  • The Greedy Cookie Monster; grabs all the cookies he thinks he might eat, but never eats all of them and never returns any – this is the thick provisioning model.
  • The Selfish Cookie Monster; only grabs cookies as he gets hungry but if he doesn’t eat them immediately, doesn’t give them back – this is thin provisioning with no zero block reclaim.  Eventually thin provisioning will become thick as all logical blocks in a LUN become mapped to physical storage.
  • The Nice Cookie Monster; takes the cookies as he gets hungry but only returns uneaten cookies if asked – this is thin provisioning with manual zero block reclaim.  A manual process is required to zero out the unused space and to return it to the free pool.
  • The Saintly Cookie Monster; takes the cookes as he gest hungry and offers them back immediately he realises he can’t eat them  – this is thin provisioning with automatic zero block or free space reclaim. 

So, of the storage arrays out there offering thin provisioning, which fit the various Cookie Monster personality types?  I’ll leave that for you to guess.

About Chris M Evans

Chris M Evans has worked in the technology industry since 1987, starting as a systems programmer on the IBM mainframe platform, while retaining an interest in storage. After working abroad, he co-founded an Internet-based music distribution company during the .com era, returning to consultancy in the new millennium. In 2009 Chris co-founded Langton Blue Ltd (www.langtonblue.com), a boutique consultancy firm focused on delivering business benefit through efficient technology deployments. Chris writes a popular blog at http://blog.architecting.it, attends many conferences and invitation-only events and can be found providing regular industry contributions through Twitter (@chrismevans) and other social media outlets.
  • http://www.businesstechforall.wordpress.com Dave Martinez

    Chris, that is a fantastic explanation of thick and thin provisioning. Other than Drobo being the Saintly Cookie Monster, what storage devices would you equate with each Cookie Monster?

  • http://www.drobo.com Jim Sherhart

    Chris – Easily the best piece I have ever read on thin provisioning. Well done.


  • Ilja Coolen


    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.


  • Pingback: Answer For Article()

  • Pingback: Tweets that mention Enterprise Computing: Thin Provisioning and The Cookie Monster! « The Storage Architect -- Topsy.com()

  • Pingback: What a Tech Field Day! – Gestalt IT()

  • http://etherealmind.com Etherealmind

    Even I understood that. And I like cookies.

  • Adriaan Serfontein


    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

  • Cucki Munster


    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.

  • Pingback: http://www.vmwareinfo.com()

  • SRJ

    Ilja – SVC 5.1 seems to be even better than Chris’ “saintly” classification because it knows in advance that it won’t eat the cookies, so doesn’t take them to begin with! What other products avoid writing the zeroes in the first place, rather than having to reclaim them later?

    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…

  • Pingback: VIRTUMANIA Episode 5: Sir Mix-A-Lot Storage Virtualization | VM /ETC()

  • http://twitter.com/StorageOlogist Lee Johns

    We have a new one at Starboard Storage.  The Abstinent Cookie Monster.  He never takes the cookies in the first place.  He is on a diet.  http://blog.starboardstorage.com/blog/bid/155959/The-Scourge-of-the-Zero-Why-nothing-may-be-ruining-the-efficiency-of-your-storage-array

  • Chris Evans


    Also 3Par InServ with the host running Symantec Storage Foundation and the Thin Reclamation API…


  • Chris Evans

    Thanks Jim, much appreciated. I will be touching on the more specific nature of Drobo reclaim in a future post.


0 Flares Twitter 0 Facebook 0 Google+ 0 StumbleUpon 0 Buffer 0 LinkedIn 0 Filament.io 0 Flares ×