Symptoms:

Datastore formatted with VMFS6 does not reclaim space automatically.

- Space-reclamation is enabled on datastore configuration

- Back-end storage array also supports the auto-space reclamation.

VMware vSphere ESXi 7.0
VMware vSphere ESXi 6.5
VMware vSphere ESXi 8.0
VMware vSphere ESXi 6.7

This is because, when VMFS is deleted, blocks are still mapped in the backing array. Upon re-creation into VMFS6, there's no efficient way for VMFS6 to know which blocks were earlier mapped by VMFS volume. So, VMFS6 will only unmap those blocks that are mapped (written) and then unmapped after creating VMFS6 volume.

There are two options to prevent this:
1) Delete the data from the original VMFS datastore, manually unmap this datastore, delete this datastore, format the same lun as VMFS6 and create new datastore.
2) Do not use the same LUN again for a new VMFS6 datastore. On a fresh LUN, there's nothing mapped. And VMFS6 Auto-Unmap is efficient in unmapping the blocks written and unmapped in VMFS6, so it works fine.

Workaround:
If the new VMFS6 datastore has already been created on a previously used LUN, write data to the datastore by creating an eager zeroed thick vm disk or using dd utility to create a bogus file so that datastores usage reaches 100%, then delete that disk/file and now auto-unmap will work as expected.

There are other causes for auto-unmap failing. Please see the following KBs:

https://kb.vmware.com/kb/51613

https://kb.vmware.com/kb/53091