The esxcli unamp command is an useful tool for reclaiming space from thin provisioned LUNs, more details on the command and it’s use can be found in this VMware KB article:
The version of vSphere we use is 5.5 and I have ran this command and reclaimed space before without any issues, however, on one particular LUN although the command didn’t throw any errors upon inspecting the LUN no space had been reclaimed!
Trawling through the logs showed the following:
total clone read ops:0
total clone write ops:0
total blocks read for clone:0
total blocks written for clone:0
total clone failures:0
total ATS cmds:7034525
total ATS failures:0
total zero cmds:2
total zero failures:0
total blocks zeroed:2064
total delete cmds:46463
total delete failures:0
total blocks deleted:1356115968
total unaligned ats, clone, zero, delete ops:0
Average latency measured over all issued commands:501
Moving Average latency of device:18198
No errors, in fact total delete cmds:46463 is shown so I should have reclaimed quite a few GB of space. This leads me to conclude there must be an issue on the storage array. Searching through several vendor documentation revealed the following:
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, before running operations that result in unmap commands being sent to the array, disable replication (including Synchronous Replication) on the volume.
Indeed, that particular LUN was being replicated hence no space could be reclaimed. Once replicas were deleted unmap command worked successfully.
So be cautious, if you are replicating a LUN then the unmap command won’t be able to free up any space – at least not on a Dell Equallogic SAN.