refs volume deletion fails to reclaim san capacity

Question

“Optimize-Volume -ReTrim” completes without errors, but deleting several terabytes from our ReFS volume still does not return the freed space to the SAN array. i already tried running ReTrim manually and rebooting the Windows Server, but the thin-provisioned capacity remains fully allocated. I contacted the SAN vendor and a local Windows specialist, but neither could fix it. We cannot afford to loose this storage capacity because the array is nearly full and critical production workloads depend on it. your support team is our only hope . i'm running out of options.

Answer 1

Hi @Syafiq Hamid

Since Optimize-Volume -ReTrim completes successfully but the thin-provisioned SAN capacity remains allocated, I would first separate Windows issuing UNMAP/TRIM from the storage array actually reclaiming those blocks.

Deleting files on ReFS makes space available to Windows, but SAN reclamation also depends on the complete storage path supporting and correctly processing SCSI UNMAP.

First, verify that Windows hasn't disabled delete notifications:

fsutil behavior query DisableDeleteNotify

Microsoft documents DisableDeleteNotify = 0 as allowing TRIM/UNMAP notifications.

Then check how Windows sees the underlying storage:

Get-Volume
Get-Disk
Get-PhysicalDisk
Get-StoragePool

I'd also run:

Optimize-Volume -DriveLetter X -ReTrim -Verbose

and capture the verbose output.

The important point is that a successful ReTrim operation doesn't necessarily mean several TB will immediately disappear from the SAN's allocated-capacity counter. The Windows storage stack can issue reclamation requests successfully while the array subsequently handles UNMAP asynchronously, applies its own reclamation thresholds, or doesn't pass UNMAP correctly through some layer of the storage path.

Since this is ReFS, I would also check whether deleted data is still referenced by something such as VSS snapshots, backup snapshots/clones, ReFS block cloning, or another storage-layer snapshot mechanism. If blocks remain referenced, they cannot simply be returned to the thin-provisioned pool.

I would not format the volume or perform destructive disk operations while the array is nearly full.

Given the production impact, the most useful next diagnostic is to determine whether UNMAP commands are actually reaching the SAN. If the SAN vendor can trace SCSI commands on the relevant LUN while you run:

Optimize-Volume -DriveLetter X -ReTrim -Verbose

you can distinguish between:

Windows doesn't issue UNMAP → Windows/storage-stack investigation versus SAN receives UNMAP but capacity isn't reclaimed → array-side reclamation investigation

If you can provide the Windows Server version/build, SAN model, connection type (FC/iSCSI), whether MPIO is involved, fsutil behavior query DisableDeleteNotify output, and the verbose Optimize-Volume result, we can narrow down where reclamation is stopping.

Microsoft also documents that Optimize-Volume -ReTrim generates TRIM/UNMAP hints for unused sectors on thinly provisioned storage.

Sharing these references with you:

Microsoft Learn — fsutil behavior | https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior

Microsoft Learn — Optimize-Volume | https://learn.microsoft.com/en-us/powershell/module/storage/optimize-volume

Please "Accept the Answer" if this information helped you. This will help us and others in the community.