What is UNMAP?: UNMAP (SCSI command 0x42) is the mechanism that allows a host (like ESXi) to inform the storage array that specific blocks of data are no longer in use (e.g., after a VM is deleted or moved). This is critical for Pure Storage because it allows the array to reclaim that space and maintain high data reduction ratios.

Evolution in ESXi: In versions prior to 6.5, UNMAP was a manual process executed via the CLI. Starting with ESXi 6.7, VMware introduced Automatic Space Reclamation, which runs in the background.

The Pure Storage Recommendation: Pure Storage recommends setting the reclamation priority to Auto with Low Priority.

Low Priority: This ensures that the UNMAP commands are sent to the FlashArray at a steady, manageable rate (roughly up to 25 MB/s to 100 MB/s depending on the Purity version). Because FlashArrays are built on a high-performance metadata engine, 'Low Priority' is more than sufficient to keep up with even high-churn environments without causing any contention for active application I/O.

Why avoid High Priority (Option B)?: Setting it to high priority or using a fixed high-burst rate can lead to 'bursty' SCSI traffic. While the FlashArray can handle the load, it is considered a best practice to keep background maintenance tasks like space reclamation at a lower priority to ensure the 'Big Three' (latency, bandwidth, IOPS) for production workloads remain optimized.

Verification: You can verify that UNMAP is working by looking at the Data Reduction metrics in the Purity GUI or Pure1. If the 'Thin Provisioning' or 'Reclaimed' numbers are increasing after file deletions, the host is correctly communicating its freed space to the array.