This issue has been fixed in ESXi 6.5.0d, build-5310538, available at
VMware Downloads. Upgrading to this version, or a newer version, will prevent new datastores from being created with the wrong start sector, but it will not fix existing datastores.
For long-term resolution, for those datastores that were already created with the wrong start sector (128), follow these steps:
- Upgrade to ESXi 6.5.0d, build-5310538, or newer version of ESXi.
- Create new datastores.
- Migrate the VMs from the faulty datastores to the new datastores
- Delete the faulty datastores.
After this is done, you should have no further troubles with automatic UNMAP, thus it will prevent the datastore disk space issue.
Workaround:
To work around this issue:
- From an ESXi host command line, you can fill the free space in the file system with zeros, using the esxcli storage vmfs unmap -u command:
For example: esxcli storage vmfs unmap -u 58e36bcd-396ca5a1-f37b-6c3be5b653b8
Note: Give the above task some time to complete, as the array will have some work to do, after the ESXi host command has completed the zero operation, and we cannot tell when the array gets done. Maybe wait until the next day. Then you can manually run the reclaim operation, mentioned in your storage array management software documentation, through the array management software.