Many application have the tendency to write zeroes to the free space as part of the standard initialization, allocation or migration processes. Depending on the environment, this might be a waste of space for the customers. There is a possibility of reclaiming this space and the process is called "Zero Space Reclamation" in EMC terminology.
Generally speaking when a file is deleted from a file system, it is removed from the file system from being referenced and becomes inaccessible for the file system, however the data on the disk is still non zero and contains the original disk contents. Over time, as the files are continuously added and deleted there might be chances that most of the file system might have non zero data though the file system might report that lot of space is available to use. When these devices are migrated, depending on the migration tool used, it is possible that this non zero data also gets migrated to the new environment which is actually waste of resources.
Generally thick devices used by many applications will have the pre-allocated zero data chunks. Suppose if you have a 40 GB device which is only 20 GB used and you are going to migrate it to a thin device using a migration tool which copies pre-allocated zero data also, now after migration you will notice that the actual usage of the thin device from the thin pool is way more than 20 GB though it should only use 20 GB as it's a thin device. The reason for this is that during migration, extra pre-allocated zero data has also been copied along with any "deleted non zero data" which together accounts for this inflated size. This is actually waste of resources for the user and here "zero space reclamation" is useful.
With Enginuity 5875.135.91 onwards, SRDF supports zero space reclamation while replicating the data from thick LUN to thin LUN. Earlier supported only for FBA devices but with latest releases CKD devices are also supported). Zero space reclamation is an Enginuity feature which allows you to remotely mirror a thick SRDF device with a thin SRDF device while avoiding mirroring the pre allocated zero data chunks that may be associated with a thick SRDF device.
When we start space reclamation process, it starts a back end disk adaptor task to examine the allocated thin device extents for the specified thin devices. A thin device extent is 768 KB (or 12 tracks) in size and is the default unit of the storage at which data is stored in thin devices. For each extent all the 12 tracks will be brought in to symmetrix cache and will be examined if they all contained all zero data. If the entire extent contains all zero data, the extent will be de-allocated and added back to the pool, which will make it available for the next extent allocation . Should any portion of the extent contains some data, none of the extent is reclaimed.
You can trigger the Zero space reclamation using SYMCLI or via Unisphere GUI. You can run a "symconfigure" command with "start reclaim" command line to start the process. Below example will give you clarity.
root# symconfigure -sid 1234 -cmd "start reclaim on tdev 0345;" commit
Once initiated, the status of the thin device will change from "bound" to " reclaiming". You can run the below command to see the status.
root# symcfg -sid 1234 show -thin -pool FC -detail -GB
It is a very simple process using Unisphere GUI. Just select the tdev, right click and select "start allocate/free/reclaim" and then select start reclaim.
