The IBM DS8880 family supports Thin Provisioning for a huge number of operating systems, like z Systems, IBM i or distributed systems.
One general issue with Thin Provisioning is how to get unused storage capacity back, if one of the thinly provisioned volumes had been written to, physical storage got allocated, but then this content is no longer needed and should be discarded.
For z Systems, a newer DFSMSdss command SPACEREL exists, which can be used to release physical space which was allocated, but not yet given back when the data was logically deleted.
For open systems, the Veritas InfoScale (Veritas Volume Manager) software for a long time was the only choice with DS8000 to selectively release some partial capacity back to the operating system, unless you'd initialise the entire volume. This Veritas option is for instance documented here:
For AIX 7.2, then another way exists to reclaim, based on SCSI WRITE_SAME, and described under: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/Storage%20Space%20Unmap%20Support%20in%20AIX .
Now with the DS8000 R8.2.3 release this June (bundles 88.23 and higher), the DS8880 also supports the VMware SCSI UNMAP option, along with the VAAI and VASA APIs which we had been supporting before.
When space is released from the vSphere layer, it can be returned to the DS8880 for alternative use with this function.
DS8880 works with two possible extent sizes, 1 GiB or 16 MiB, which also determine the allocation when deploying Thin Provisioning, on these "ESE" (Extent Space Efficient) volumes.
For VMware UNMAP, the small-extent option (16 MiB / non-default) should be used throughout – and in general with thin provisioning, the small extents offer a much better space efficiency. Using vSphere ESXi 5.0 and higher, on ESE volumes which are not in copy-service relationships the VMware can release any such space no longer in use.
Find a more detailed how-to of this function in either:
https://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD106413 - or in the following blog article of our ISV colleagues: