Version 6.0 of the PS Series firmware introduces support for using SCSI unmap operations to recover unused space previously allocated to volumes.

As a host writes data to a volume, the array allocates additional space for that data. Prior to support of the volume unmapping feature, that space remained allocated to the volume, even if the data was deleted from the volume and hosts were no longer using it. This created a “watermark” effect; the array could not de-allocate the space, and therefore the space was unavailable for allocation to other volumes.

With volume unmapping, the array can reclaim this unused space. When a host connected to a volume issues a SCSI unmap operation, the array deletes the data and de-allocates the space, making it available for allocation by other volumes.
Volume unmapping requires that all group members be running Version 6.0 or later of the PS Series firmware. Space de-allocation occurs only if you are using initiators that are capable of sending SCSI unmap operations and only on a “best effort” basis. Although space de-allocation occurs on both thin provisioned volumes and regular volumes, the volume reserve size can potentially shrink as a result of unmap operations only on thin provisioned volumes.

If space is de-allocated, that space might not be immediately available as free space for other volumes until the array deletes snapshots of those volumes.
Unmap operations are supported in the following operating systems:

• VMware ESX 5.0
• Red Hat Enterprise Linux 6.0
• Windows 8/Windows Server 2012

Running Defrag Tools

Run defragmentation tools (such as fstrim, windows manual defrag, or esxtool), during periods of low I/O activity, since these operations might result in large numbers of unmapping operations and negatively impact array performance.
Unmapping and Replicated Volumes

It is not advisable to run operations that result in SCSI unmap operations (for example, format or defrag) on volumes on which replication (including Synchronous Replication) is enabled.

Such operations on replicated volumes result in zeros being written to the destination sectors of the volume. This writing of zeros can cause the operations to take a very long time to complete, and no space is reclaimed. Therefore, Dell recommends that you disable unmapping on hosts or volumes (depending on the host operating system) that are using replicated volumes. Refer to the following sections for information on disabling and enabling unmapping in VMware ESX, Red Hat Enterprise Linux, or Windows 8/Windows Server 2012 operating systems.
Using Unmapping with VMware

In VMWare® ESX™ 5.0, automatic unmapping is enabled by default for deletion operations such as deleting or migrating a VM.

However, Patch ESXi500-201112001, a recommended patch for ESX 5.0, disables automatic unmapping. If you are running this patch, you can enable unmapping using the -y argument to the vmkfstools utility, which performs manually invoked unmapping and space reclamation on a per volume basis.

For more information about using vmkfstools, refer to the VMware Knowledge Base.
Using Unmapping with Red Hat Enterprise Linux

By default, unmapping is disabled in Red Hat Enterprise Linux.

Linux file systems that support unmap operations, such as ext4 on Red Hat Enterprise Linux 6, must be mounted with the-o discard option to enable free space recovery functionality. If the file system does not support the-o discardmount option, it does not support free space recovery on PS Series storage array volumes.

When free space recovery via volume unmapping is enabled, very large files are deleted and their space is reclaimed. However, volume unmapping operations can stop new writes to the volume and adversely affect performance. This scenario is most likely with replicated volumes. Therefore, Dell recommends that you do not use volume unmapping with replicated volumes. Also, running mkfs, defragging, or deleting files on file systems mounted using the-o discard option can generate large numbers of unmap operations, which are not recommended for replicated volumes.

Using Unmapping with Windows 8/Windows Server 2012

By default, unmapping is enabled in Windows 8/Windows Server 2012, which automatically detects a volume’s provisioning capabilities, including whether or not the volume can process unmap operations. When data is deleted from a volume in Windows, the corresponding space on the PS Series storage array volume is also freed automatically, thus maximizing the efficiency of the array.

To disable unmapping in Windows 8/Windows Server 2012, issue the following command:

fsutil behavior set disabledeletenotify 1

To reenable unmapping, issue the following command:
fsutil behavior set disabledeletenotify 0

To check the current setting of unmapping, issue the following command:
fsuitl behavior query disabledeletenotify

Note:
The disabledeletenotify setting is a global operating system setting that not only disables unmap operations from being sent to the PS Series storage arrays, but also disables TRIM to SSDs. For more information about the fsutil utility, see technet.microsoft.com/en-us/library/cc785435(v=ws.10).aspx

Automatic defrag can generate a large number of unmap operations, which are not recommended for replicated volumes. Therefore, in Windows Server 12, turn off automatic defrag for replicated volumes.