Home > Storage > PowerMax and VMAX > Storage Admin > Dell PowerMax and VMware vSphere Configuration Guide > Dead Space Reclamation (UNMAP)
Referred to as Dead Space Reclamation by VMware or simply UNMAP, the SCSI UNMAP command (0x42) issues requests to de-allocate extents on a thin device. The purpose behind UNMAP is the reclamation of space on the array. UNMAP can be utilized in two different scenarios. The first is to free space in a VMFS datastore - manually or automatically. The second is to free space in a thin vmdk that is part of a Guest OS in a VM. This is known as Guest OS, or in-guest UNMAP. It supports both VMFS and vVol datastores.
As virtual machines are created and grow, then are moved or deleted, space is stranded in the thin pool because the array does not know that the blocks where the data once resided is no longer needed. Prior to the integration of this new Storage API in vSphere, reclamation of space required zeroing out the unused data in the pool and then running a zero reclaim process on the array. With UNMAP support, vSphere tells the PowerMax what blocks can be unmapped or reclaimed. If those blocks span a complete extent or extents, they are deallocated and returned to the thin pool for reuse. If the range covers only some tracks in an extent, those tracks are marked as available on the PowerMax but the extent cannot be deallocated. This is still beneficial, however, as those tracks do not have to be retrieved from disk should a read request be performed. Instead, the PowerMax array immediately returns all zeros.
VMware will, of course, reuse existing space in the datastore even if the data has not been reclaimed on the array; however, it may not be able to use all of the space for a variety of reasons. In addition, by reclaiming the space in the thin pool it becomes available to any device in the pool, not just the one backing the datastore. The use of the SCSI command UNMAP, whether issued manually or automatically, is the only way to guarantee that the full amount of space is reclaimed for the datastore.
Guest OS or in-guest UNMAP was introduced in vSphere 6.0. In the initial release it supported Windows 2012 R2 and higher but not Linux. In vSphere 6.5 SPC-4 support was added which enables Guest OS UNMAP for Linux VMs. There are a number of prerequisites that must be met to take advantage of Guest OS UNMAP. There are some differences between the two vSphere versions that should be noted. They are covered in the next two sections.
To enable Guest OS UNMAP in vSphere 6.0, the prerequisites are as follows:
esxcli system settings advanced set --int-value 1 --option /VMFS3/EnableBlockDelete
An important note is that change block tracking (CBT) is not supported with Guest OS UNMAP in vSphere 6.0 but is supported in vSphere 6.5 and higher.
To enable Guest OS UNMAP in vSphere 6.5 and higher, the prerequisites are as follows:
esxcli system settings advanced set --int-value 1 --option /VMFS3/EnableBlockDelete
While Windows automatically issues UNMAP, Linux does not do so by default. Though sg_unmap and fstrim can be issued manually to free space, a simple parameter is available on file systems to reclaim space automatically. When mounting the file system (e.g., ext4), use the discard option and all deleted files will cause UNMAP to be issued. Here is an example.
mount /dev/sdb1 /u02 -o discard
To confirm that UNMAP is in fact supported on a LUN, the following command can be issued to query the device:
esxcli storage core device vaai status get -d <naa>
Example output:
naa.<naa>
VAAI Plugin Name: VMW_VAAI_SYMM
ATS Status: supported
Clone Status: supported
Zero Status: supported
Delete Status: supported
A device displaying Delete Status as supported means that the device is capable of receiving SCSI UNMAP commands.