So here's what I've concluded after running some tests for VMware, Eager Thick vmdks and 3par:
esxcli storage vmfs unmap in 5.5 or
vmkfstools -y in 5.1 command on the datastore itself will unmap only free space as seen by ESXi. For example you have the following:
2TB thin volume on 3par, reserved user size 100%
This volume is an ESXi 2TB VMFS5 datastore, which has 1.5TB of Eager Thick vmdk files
When you issue unmap command from ESXi it will free up around 0.5TB. ESXi doesn't see free space inside thick vmdk. You will see this reflect on 3par's Volume Reserved user size in approximately 12 hours time (in my case on 7400).
---------------
Now, we look one level below at the OS level inside vmdk files. By default Windows Server prior to 2012 does not zero deleted space so we have have to use sdelete or powershell script (please see below) to write zeros in empty space. For example we have the following:
2TB thin volume on 3par, reserved user size 100%
This volume is an ESXi 2TB VMFS datastore, which has 1.5TB Eager Thick vmdk file
This vmdk file is Windows Server 2008 R2, which shows 1TB free (inside the OS)
Then you zero empty space inside OS (either by sdelete or powershell script) VMware volume will be still showing as 1.5 out of 2TB used. 3par will detect these zeros and it will be reflected in Reserved User Size, it will detect approximately 1TB free (which is returned to the pool).
Conclusion:
In order to "return" unused space on 3par thin provisioned volumes back to the pool you need to run
unmap on ESXi datastore as well as zero-delete inside vmdk on OS level as they address different portions of "free" space. Additionally, "free" space will not reflect on 3par instantly; please allow at least 12 hours (maybe someone can comment more on this).
Appendix
Powershell script, alternative to sdelete
http://blog.whatsupduck.net/2012/03/pow ... elete.htmlFor Linux "zeroing" read this page:
http://intgat.tigress.co.uk/rmy/uml/index.html