vSAN storage space is not reclaimed after deleting data and running TRIM/UNMAP in Guest OS

Products

• VMware vSAN

Issue/Introduction

vSAN backend storage usage may not decrease even after large amounts of data are deleted from within a Guest OS. Despite enabling Guest UNMAP/TRIM and successfully running manual trim commands (e.g., defrag E: /L), the vSAN capacity remains high, showing a significant discrepancy between the reported data and the physical vSAN object usage.

Symptoms:

• The Guest OS reports "Trim successful," but vSAN "Used" space remains unchanged.
• A large discrepancy (e.g., 10+ TB) exists between Guest OS file usage and vSAN backend capacity.

C:\Windows\system32>defrag E: /L
Microsoft Drive Optimizer
Copyright (c) 2013 Microsoft Corp.

Invoking retrim on New Volume (E:)...

The operation completed successfully.

Post Defragmentation Report:

        Volume Information:
                Volume size                 = 22.36 TB
                Free space                  = 9.28 TB

        Retrim:
                Total space trimmed         = 9.22 TB

• esxtop monitoring shows negligible UMP MBS/s (Unmap throughput) despite TRIM activity in the Guest

Example esxtop output showing stalled reclamation (0.01 MB/s): 

GID       VMNAME          VDEVNAME   NVDISK    CMDS/s     READS/s WRITES/s  MBREAD/s MBWRTN/s  LAT/rd  LAT/wr    SC UMP/s FL UMP/s UMP/s    SC UMP MBS/s FL UMP MBS/s
20#####09 VirtualMachine  -          2         12.97      0.38    12.59     0.01     0.07      0.256   0.636      0.38     0.00     0.38     0.01        0.00

Environment

• Platform: VxRail Cluster / VMware vSAN
• vSAN Policy: RAID-5 (Erasure Coding) or RAID-6
• Guest OS: Windows Server
• VM Hardware: Version 11 or higher

Cause

The issue may stem from a configuration gap where the VM-level advanced parameter disk.scsiUnmapAllowed is missing or set to False, preventing UNMAP commands from reaching the vSAN layer - combined with alignment mismatches, vSAN reclaims space in chunks of 4MB. If the guest OS filesystem (for example, NTFS with 8KB clusters) is highly fragmented, it can’t provide a full 4MB block of unused space to the storage layer. Even a small amount of active data such as a single 8KB cluster within a 4MB range prevents vSAN from reclaiming that space, resulting in the entire 4MB block remaining allocated.

Configuration of E: drive: "Bytes Per Cluster."
C:\Windows\system32>fsutil fsinfo ntfsinfo E:
NTFS Volume Serial Number :       0x802############
NTFS Version              :       3.1
LFS Version               :       2.0
Number Sectors            :       0x0000000b2########
Total Clusters            :       0x0000000b2######
Free Clusters             :       0x000000004a##########
Total Reserved            :       0x0000000000######
Bytes Per Sector          :       512
Bytes Per Physical Sector :       512
Bytes Per Cluster         :       8192 < -- 8 KB
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length     :       0x00000007##########
Mft Start Lcn             :       0x0000000000#########
Mft2 Start Lcn            :       0x00000003##########
Mft Zone Start            :       0x0000000############
Mft Zone End              :       0x00000###########
Max Device Trim Extent Count :    64
Max Device Trim Byte Count   :    0xffffffff
Max Volume Trim Extent Count :    62
Max Volume Trim Byte Count   :    0x40000000

Resolution

To resolve this issue, the communication path must be enabled and the data must be consolidated to meet vSAN's 4MB alignment requirement.

• Verify Guest OS Settings Procedure to Enable TRIM/UNMAP to reclaim space on vSAN datastore.

  • Open PowerShell as Administrator and run the following to ensure DisableDeleteNotification is set to 0 (Enabled):

Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\FileSystem" -Name DisableDeleteNotification

• Enable UNMAP on the VM
  
  

• Monitor Physical Reclamation:

  • SSH into the ESXi host where the VM resides.
  • Run esxtop, then press v (VM view), then f (Fields), and L (unmap stats).
  • Monitor the SC UMP/s (Unmap commands) and UMP MBS/s (Throughput) columns. Throughput should surge (e.g., >1000 MB/s) during successful reclamation.

Additional Information

• RAID-5/6 Overhead: RAID-5 (3+1) has a 1.33x overhead. 10TB of logical data will consume approximately 13.3TB of physical vSAN space.
• Operational Patience: Reclamation is a low-priority background task. For multi-TB volumes on RAID-5, allow 24–48 hours for the process to complete due to the Read-Modify-Write overhead