Microsoft Virtualization Discussions

The Thin provision fallacy


Thin provisioning sure sounds like a good idea, too bad that over time the storage system can’t tell what is actually unused space.  Without this ‘knowledge’ the storage system cannot reclaim the unused space and this renders the process of thin provisioning practically useless.


With a thin provisioned volume what you really end up with is an ever increasing high-water mark being set on the used space in your volumes.  The problem is that the operating systems that are using the storage system (ESX in my world) don’t tell the storage system what they delete or mark as free space.  Without this communication between the hosts and the storage system, thin provisioning is only a poorly implemented good idea.

There are ‘hacks’ out there that will go and write zeros across the LUNs.   By writing zeros to large sections of the LUNS the storage system can tell that the space is unused.  But, if you are going to implement a feature of your storage system you shouldn’t have to rely on a hack to make it really work.  Seems more than a little deceptive to me.  I am curious how others are dealing with the thin provisioning fallacy.



There is SCSI UNMAP which is gradually starting to be supported by both storage vendors and OS vendors.


Good points and a challenge for many vendors. With ntfs and snapdrive there is space reclamation to deal with this from the host side. With virtualized hosts we still see 50% or more dedup which helps and thin give that space back to the volume


Well, the first thing which springs to my mind - ever considered using NFS shares, rather than LUNs for ESX?

Other than that, you can find some details about UNMAP feature in vSphere 5 here:

There is some discussion in the comments about issues with UNMAP, but apparently it got resolved in ESXi 5.0 Patch 02.




resolved in ESXi 5.0 Patch 02.

hmm, just reading VMware KB: "This patch resolves the issue by disabling the space reclamation feature, by default" - not the kind of resolution I was hoping for...


Unfortunately, NFS does not really help as long as VMDK are not deleted; nor UNMAP support in ESX5. Here we need explicit support from hypervisor first. I am not sure whether ESX offers any right now; I hope it is on their roadmap.


NFS does not really help as long as VMDK are not deleted

yes, sure - but if we are talking about white space within VMDKs (not within datastore), then in a case SnapDrive for Windows space reclamation (hole punching) may help.