After a host writes to a thin provisioned volume, the physical capacity is allocated to the host file system. Unfortunately, if the host deletes the file, only the host file system frees up that space. The physical capacity of the storage system remains unchanged. The storage system does not free up the capacity from the deleted host file; this capacity is commonly referred to as “dead space”. Obviously, this method is not the most effective one for handling back-end block-level storage. Ideally, when a host deletes files, that space should be reclaimed by the host file system and the back-end storage system.
This Technote explains how the IBM XIV Storage System Gen3 with IBM XIV Storage Software V11.2 can now fully use its thin provisioning capability by enabling support for the Windows Server 2012 space reclamation feature.
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.
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
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:
This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.