Thin provisioning provides a specified volume size but uses physical storage only when it is needed. Although this sounds like a great way to use the available storage space efficiently, it might not be possible always. When files are deleted or moved, the now unused data is usually still on the physical storage. The host system might indicate that the used capacity is now smaller, but the physical storage is still in use and remains allocated to that host system.

Space reclamation deals with this situation by providing a way for the host system to indicate that the physical storage that is assigned to it is no longer in use. Various host operating systems deal with this process differently so the various commands that are used and the amount of space that is reclaimed might vary.


Space reclamation architecture

Space reclamation in many operating systems is typically achieved by running the Small Computer System Interface (SCSI) Write Same or the SCSI UMAP commands. Which command you use depends on the operating system that is involved.

These SCSI primitive commands have different characteristics and might reclaim various amounts of capacity.

Windows 2012 Server uses the UNMAP command for space reclamation.


UNMAP command

Starting with XIV Storage Software V11.2, the XIV Storage System Gen3 provides support for the SCSI UNMAP function, which is natively available with Microsoft Windows Server 2012.

The UNMAP command has the following characteristics:

• Deallocates a partition and immediately make the capacity available to other volumes.
• The command does not increase the physical capacity that is used.
• The command is not guaranteed to complete and might fail silently, depending on the conditions in the storage system.

XIV space reclamation considerations

The XIV architecture is thinly provisioned. The effectiveness of space reclamation depends on how the operating system interacts with the XIV architecture. The smallest unit of capacity that can be freed is a partition (1 MB). Although the partitions may be freed, the change in physical capacity (hard space) might not be noticeable because the XIV GUI displays the allocation in multiples of the minimum XIV allocation size (17 GB).

The usage of XIV Snapshots affects the ability to reclaim space. Obviously, data that is preserved by a snapshot cannot be reclaimed because it is in use by the snapshot.

UNMAP might result in snapshots being deleted if additional pool space is needed. Additional space is usually needed because of the possible delay in running UNMAP on unused data.

UNMAP is supported for volumes that use synchronous mirroring if all the XIV storage systems are using Version 11.2.

UNMAP is not supported for volumes that use asynchronous mirroring.


Windows 2012 space reclamation

Volumes are created in a thin pool on the XIV Storage System and are defined to a Windows 2012 Server by using the XIV Host Attachment Kit. Windows recognizes that these volumes are thin provisioned drives.

The Optimize Drives menu, which is part of the Windows tools, shows the space efficiency and analyzes and optimize drives as needed, as shown in the following figure.


Figure 1. Optimize Drives menu

The space reclamation occurs automatically as files are deleted or moved. The analyze option can verify the state of the thin provisioned volumes.

In this scenario, files are created on the drives and use 67 GB of physical space, as shown in the following figure.


Figure 2. Initial volume size

The XIV GUI displays the volume capacity, which shows 67 GB capacity in the following figure.


Figure 3. Initial volume capacity


Deleting files

When you delete files normally, the actual space that is allocated on the XIV Storage System does not change. However, with space reclamation active, the UNMAP command identifies the unused space and the XIV Storage System indicates that the volume's allocated size has decreased.

As shown in the following figure, after you delete files on Volume 2, the Windows properties menu indicates that 33 GB are now allocated.


Figure 4. Volume size after deleting files

If you view the XIV GUI Volumes by Pools window, it shows that the Volume 2 hard capacity is reduced to 33 GB as well.


Figure 5. Volume capacity after deleting files

Attention: The space reduction occurs after the actual file deletion, so there might be a delay of up to 30 seconds before the reduction in hard capacity is seen.

For more information, see IBM Redpaper publication XIV Thin Provisioning and Space Reclamation, REDP-5001, which can be found at the following website:
http://www.redbooks.ibm.com/abstracts/redp5001.html