B: Reclaiming Storage from Disk Pools
How Much Storage will be Reclaimed?
This is impossible to predict. SANsymphony can only reclaim Storage Allocation Units that have no block-level data on them. If a host writes its data ‘all over’ its own filesystem, rather than contiguously, the amount of storage that can be reclaimed may be significantly less than expected.
Defragmenting data on served virtual disks
A VMFS volume cannot be defragmented. See: https://kb.vmware.com/s/article/1006810.
Notes on SANsymphony's Reclamation Feature
Automatic Reclamation
SANsymphony checks for any ‘zero’ write I/O as it is received by the Disk Pool and keeps track of which block addresses they were sent to. When all the blocks of an allocated SAU have received ‘zero’ write I/O, the storage used by the SAU is then reclaimed. Mirrored and replicated virtual disks will mirror/replicate the ‘zero’ write I/O so that storage can be reclaimed on the mirror/replication destination DataCore Server in the same way.
Manual Reclamation
SANsymphony checks for ‘zero’ block data by sending read I/O to the storage. When all the blocks of an allocated SAU are detected as having ‘zero’ data on them, the storage used by the SAU is then reclaimed.
Mirrored virtual disks will receive the manual reclamation ‘request’ on all DataCore Servers involved in the mirror configuration at the same time and each DataCore Server will read from its own storage. The Manual reclamation ‘request’ is not sent to replication destination DataCore Servers from the source. Replication destinations will need to be manually reclaimed separately.
Reclaiming Storage on the Host using VAAI
When used in conjunction with either VMware’s vmkfstools or their own esxcli command, the ‘Block Delete/SCSI UNMAP’ VAAI primitive will allow ESXi hosts (and their VMs) to trigger SANsymphony's ‘Automatic Reclamation’ function.
Thin Provisioning Block Space Reclamation (VAAI UNMAP) does not work if the volume is not native VMFS-5 (i.e., it is converted from VMFS-3) or the partition table of the LUN was created manually
See: https://kb.vmware.com/s/article/2048466.
Space reclamation priority setting
DataCore recommend using the 'Low' space reclamation priority setting. Any other settings could result in excessive I/O loads being generated on the DataCore Server (with large numbers of SCSI UNMAP commands) and this may then cause unnecessary increases in I/O latency.
Space reclamation granularity setting
DataCore recommend using 1MB.
Reclaiming Storage on the Host Manually
Create a new VMDK using ‘Thick Provisioning Eager Zero’
A suggestion would be to create an appropriately sized virtual disk device (VMDK) where the storage needs to be reclaimed and ‘zero-fill’ it by formatting as a ‘Thick Provisioning Eager Zero’ Hard Disk.
- Using vSphere
Add a new ‘Hard Disk’ to the ESXi Datastore of a size less than or equal to the free space reported by ESXi and choose ‘Disk Provisioning: Thick Provisioned Eager Zero’. Once the creation of the VMDK has completed (and storage has been reclaimed from the Disk Pool), this VMDK can be deleted. - Using the command line
An example:vmkfstools -c [size] -d eagerzeroedthick /vmfs/volumes/[mydummydir]/[mydummy.vmdk]
Where ‘[size]’ is less than or equal to the free space reported by ESXi.
Once the creation of the VMDK has completed (and storage has been reclaimed from the Disk Pool), this VMDK can be deleted.
For Raw Device Mapped virtual disks
Virtual Machines that access SANsymphony virtual disks as RDM devices may be able to generate ‘all-zero’ write I/O patterns using the VM’s operating systems own tools. Examples include ‘sdelete’ for Microsoft Windows VMs or ‘dd’ for UNIX/Linux VMs.
Also see:
Space Reclamation Requests from Guest Operating Systems