VMFS 6 - No more manual unmap
Six years later, vSphere 6 entered the market, including version 6 of the VMFS file system. Yay! Unmap is now an automatic behavior . . . but it’s not immediate. Some legacy storage doesn’t do well with large unmap jobs, so in VMFS 6, it can take up to a day to see the space reclaimed from delete actions.
It is recommended that you leave auto unmap as a background task if you have an older storage platform. If your environment has high storage turn-over or if you are just a fan of instant gratification, and you have a newer array, you can tune VMFS 6 to process the unmap faster when the guest OS deletes the blocks.
If you want to increase the rate of the unmap operations, the quickest way is to set the space reclamation priority. To set this to anything other than “none” or “low”, you’ll need to drop out to the esxcli to set the reclaim configuration. Changing the priority from low (the default) to medium will double the rate at which the host send unmap command from 25-50 MB/sec to 50-100 MB/sec. Hopefully you are asking yourself, “how will my array respond to that?” Before you make any changes in the automatic unmap configuration, you’ll need to check the specs and recommendations for your specific array.
One last note, if your array uses anything larger than 1MB for it’s unmap granularity, VMFS 6 won’t perform the auto unmap, it only works with 1MB granularity. If your storage arrays uses a larger unmap granularity, you’ll still need to periodically run the manual unmap command.