Space reclamation (UNMAP) is slow on Storage array

Products

• VMware vSphere ESXi

Issue/Introduction

Symptoms

• Space is reclaimed immediately on the VMFS datastore, but array-level free space updates are significantly delayed.

• esxtop shows active UNMAP (Delete) commands being sent, but throughput is low.

• VMDKs are confirmed as Thin Provisioned and VAAI Delete status is "supported".

Environment

• VMware ESXi 7.x

• VMware ESXi 8.x

Cause

In VMFS6, automatic space reclamation is an asynchronous background process.

To prevent I/O impact on production VMs, ESXi defaults the reclamation priority to "low" and throttles the bandwidth to 100 MB/s. For environments with high data turnover, these default throttles may be too restrictive, causing the array to fall behind in block deallocation.

Resolution

Follow the step to increase the reclamation bandwidth limit:

1. Verify the current reclamation bandwidth and priority: esxcli storage vmfs reclaim config get -l <Datastore_Name>

2. Consult with the storage vendor to determine the maximum safe UNMAP bandwidth for the specific array model.

3. Increase the reclamation bandwidth limit (Example: Setting to 200 MB/s): esxcli storage vmfs reclaim config set -l <Datastore_Name> -b 200

4. If the delay persists and the array can handle higher metadata overhead, adjust the priority from low to a higher fixed rate: esxcli storage vmfs reclaim config set -l <Datastore_Name> -p <medium|high> 
   Note: Monitoring VM latency during this change is recommended, as high-priority UNMAP can impact storage performance.

5. If immediate reclamation is required for a specific volume, trigger a manual UNMAP to bypass the background throttle: esxcli storage vmfs unmap --volume-label=<Datastore_Name> --reclaim-unit=200

Additional Information

Reference article: 

How to throttle the unmap requests on Datastore ( Space Reclamation )

Storage array space not reclaimed after Guest OS cleanup on VMFS