Reclaiming Thin-Provisioned Pool Capacity on Enterprise Storage

David Brown 20 Reputation points
2026-10-09T17:48:02.57+00:00

We configured thin-provisioned storage pools on our SAN array Hyper-V cluster and file servers.

The storage volumes are formatted as NTFS/ReFS and have ample free space reported inside the Windows guest operating systems.

The storage array is operating normally; however when large batches of files are deleted on the Windows clients, the array generates an urgent warning because thin-provisioned pool allocations have reached the 90% threshold without releasing blocks back to the backend tier.

Could you please clarify why this behavior occurs? How do we trigger SCSI UNMAP commands from the Windows environment to reclaim unallocated space, or are there any specific scheduled optimization requirements for the storage tier to correctly detect deleted blocks and reduce thin-provisioned allocation?

Windows for business | Windows Server | Storage high availability | Clustering and high availability
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Tracy Le 13,530 Reputation points Independent Advisor
    2026-10-09T18:25:29.9266667+00:00

    Hello David Brown,

    What you're seeing is normal behavior when the storage layer has not yet received or processed SCSI UNMAP commands. Deleting files inside Windows frees space at the file system level, but the storage array can only reclaim that capacity after the unused blocks are reported through UNMAP/TRIM.

    I would first verify that TRIM/UNMAP is enabled by checking fsutil behavior query DisableDeleteNotify, and then confirm that Windows detects the LUN as thin-provisioned. To actively trigger reclamation, run Optimize-Volume -DriveLetter X -ReTrim -Verbose on the affected volumes and monitor the array to see whether capacity begins to return to the pool.

    Since this is a Hyper‑V environment, it is also worth confirming that guests use VHDX disks attached through virtual SCSI controllers and that the storage array supports space reclamation for the presented LUNs. The exact implementation varies between storage vendors, so the array documentation should also be reviewed. If this helps, please accept the answer.

    Tracy Le.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-10-09T17:48:20.58+00:00

    This behavior occurs because deleting files inside Windows does not directly free physical capacity on a thin-provisioned SAN unless the full reclamation path is working end to end.

    Windows thin provisioning relies on space reclamation through delete notifications, file system trim, or a storage optimization operation. When a large file is deleted, Windows converts the delete or trim notification into an UNMAP request. The storage stack then translates that request into SCSI UNMAP or ATA TRIM only if the storage device reports that it supports UNMAP/TRIM correctly. If the device capability is not reported accurately, compatibility issues can occur.

    Supported reclamation triggers in Windows are:

    1. File deletion.
    2. File system level trim.
    3. A storage optimization operation.

    For thin-provisioned LUNs, storage space reclamation can be performed manually or automatically by file delete notification or by the scheduler of the Storage Optimizer utility.

    To manually trigger reclamation from Windows, run an elevated PowerShell session and use:

    Optimize-Volume -DriveLetter X -ReTrim -Verbose

    Replace X with the target volume drive letter.

    To verify that delete notifications are enabled, check:

    fsutil behavior query DisableDeleteNotify

    For ReFS, the value should be 0 for delete notifications to be enabled.

    For the SAN to actually reclaim backend pool capacity, these conditions must also be true:

    1. The LUN must be thin provisioned.
    2. The storage array must be configured to accept incoming UNMAP commands.
    3. The storage device must correctly advertise UNMAP/TRIM capability to Windows.
    4. If MPIO is used, the vendor DSM/drivers must be current so reclamation commands are not dropped in the path.

    If those conditions are met, Windows can reclaim space either automatically after deletes or through scheduled/manual optimization.

    One important caveat: on Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2, TRIM and UNMAP activity on one thin-provisioned volume can affect I/O on other volumes because intermittent I/O stalls may occur when file-delete notifications are enabled.

    Also note that if capacity on the array is being consumed by snapshots or thin clones rather than live file system allocation, UNMAP/TRIM will not reduce that snapshot-held space.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.