Many storage arrays such as HP’s 3Par line, Datacore, and others have the ability to thin provision storage. VMware also has the ability to thin provision virtual disks (VMDK files). Over time the storage utilization increases as data is created, fragmented, and moved. When data is deleted the storage array does not automatically free up the disk space in the storage pool. Block based storage arrays don’t have knowledge of what is using the LUN. It could be a raw device or have a file system such as NTFS, VMFS, EXT3, VXFS, etc. In order for most block based storage arrays to reclaim thin provisioned storage, the storage array has to find a zero bit pattern in an allocation unit of storage. That way the array knows that removing an allocation unit from a LUN and returning for reuse in the storage pool does not result in lost data. Datacore by default divides up it’s storage into 128MB segments called Storage Allocation Units or SAUs for short. 3Par uses a unit called a Chunklet which is 256MB. If the array detects only zeros in an allocation unit, it will release it from the volume to which it is assigned and return it to the storage pool for reuse.
On Microsoft Windows the commonly accepted method to write a zero bit pattern to the free space is by using the Sysinternals utility called sdelete. However, a change was made to the command line switches that effects the behavior. With sdelete v1.51 the “-c” switch wrote a zero bit pattern to free space, and the “-z” switch wrote a series of ones and zeros to securely overwrite the free space. With sdelete version 1.6 the functionality has been reversed.
If you are trying to reclaim thin provisioned space with sdelete version 1.51 or earlier you need to use the “-c” switch. For version 1.6 you need to use the “-z” switch. In case it changes in the future, you are looking for the switch referenced in the sdelete command line help that reads “Zero free space (good for virtual disk optimization)”.
