TL;DR: When you delete large amounts of data from a thin-provisioned S2D CSV on Azure Local and the storage pool's allocated size doesn't drop as expected, run slab consolidation on each affected CSV followed by Optimize-StoragePool to force the reclaim.

Recommended action:

  1. Confirm your virtual disks are thin-provisioned:

    Get-VirtualDisk | ft FriendlyName, ProvisioningType, Size

    This procedure only applies to thin-provisioned volumes.

  2. Verify the gap is real. Compare CSV file-level usage × 3 (for three-way mirror) against Get-StoragePool AllocatedSize. If they differ by tens of TB and it's been longer than 15 minutes since the deletion, proceed.

  3. For each user CSV that had data deleted, run:

    Get-Volume -FriendlyName <CSV-FriendlyName> | Optimize-Volume -Analyze -SlabConsolidate -Retrim -NormalPriority -Verbose

    These three optimization parameters (-Analyze -SlabConsolidate -Retrim) are what Optimize-Volume runs by default for thin-provisioned Storage Spaces — they're spelled out here so the operation is explicit. This is slow — expect hours per CSV depending on size and load. Run during a maintenance window if possible.

  4. After all CSVs finish, optimize the pool:

    Optimize-StoragePool -FriendlyName "SU1_Pool"

    Substitute your actual pool name from Get-StoragePool.

  5. Re-check Get-StoragePool — AllocatedSize should now reflect the deletion.

Why:

Thin-provisioned S2D virtual disks allocate storage in slabs. When files are deleted, freed regions inside slabs aren't immediately returned to the pool — slabs are only released once they're consolidated and emptied. Microsoft's guidance notes the pool can take up to 15 minutes to reflect deletions automatically (reference). When the gap persists much longer, slab consolidation is the manual lever to force the compaction.

Going forward:

There is no scheduled task that runs Optimize-Volume -SlabConsolidate automatically. The OS will eventually reclaim slab space on its own, but if you've just deleted a large amount of data and need the pool free space to reflect it, run the optimization manually. Treat this as an I/O-heavy operation — schedule it during maintenance windows and avoid running it concurrently with virtual disk repair/resync activity.

Optional details:

The slab consolidation phase is the slow part of Optimize-Volume — it can sit at 0–1% for an extended period before progressing, especially on large or busy CSVs. As long as the cluster is otherwise healthy, this is normal. You should see pool free space jump after each individual CSV's consolidation completes, not only after all of them finish.