The vxrelocd daemon runs everyday at 22:10 hours and reclaims storage on the deleted volume that are 1 day old.
The vxrelocd daemon should be running in the system to automatically reclaim the space from deleted volumes and depends on the attribute " reclaim_on_delete_wait_period" and "reclaim_on_delete_start_times" values.
How to set the reclaim_on_delete_wait_period attribute to "-1"
The reclaim_on_delete_wait_period tunable refers to the number of days to wait before starting to reclaim space on a thin LUN, after a volume using that LUN is deleted.
# vxdefault list
KEYWORD CURRENT-VALUE DEFAULT-VALUE
usefssmartmove all all
fssmartmovethreshold 100 100
sharedminorstart 33000 33000
reclaim_on_delete_wait_period 1 1
reclaim_on_delete_start_time 22:20 22:10
usesmartmovewithvvr on on
autostartvolumes on on
Specified as an integer from -1 to 366, where -1 specifies immediately and 366 specifies never.
# export POSIXLY_CORRECT=1
# vxdefault set reclaim_on_delete_wait_period -1
# vxdefault list
KEYWORD CURRENT-VALUE DEFAULT-VALUE
usefssmartmove all all
fssmartmovethreshold 100 100
sharedminorstart 33000 33000
reclaim_on_delete_wait_period -1 1
reclaim_on_delete_start_time 22:20 22:10
usesmartmovewithvvr on on
autostartvolumes on on
# vxdefault set reclaim_on_delete_wait_period -1
VxVM vxdefault INFO V-5-1-15164 Value (-1) already set for keyword (reclaim_on_delete_wait_period) pair
Thin reclamation support
Thin reclamation support is only available by default with DMP enabled, because the ASL (Array Support Library) needs to collect the thin-reclaim specific attributes which is essential for the efficient storage reclaim process. We does not have plans to enhance our ASL's to collect the same attributes with TPD (Third Party Drivers) configured on such devices.
EMC Powerpath and other third party multipathing drivers are not supported with regards to "thin reclamation" even with Veritas Volume manager 5.1 SP1 onwards
000013009
The reclaim happens at different type of regions
1. Mounted VxFS (Veritas Filesystem) filesystem. This happens by default when the 'vxdisk reclaim' command is executed, and the result output is based on this.
2. The regions on the disk where the volume is deleted. We doesn't reclaim the region of the volume when the volume is deleted.
This region gets reclaimed when the 'vxdisk reclaim' is executed a second time, or as configured in the tunable. This can be checked using the command "vxdefault list".
If vxrelocd daemon is not running, then it can be manually started by typing /usr/lib/vxvm/bin/vxrelocd &.
Command introduced in Storage Foundation 5.1:
# /usr/sbin/vxdefault list
KEYWORD CURRENT-VALUE DEFAULT-VALUE
usefssmartmove thinonly thinonly
fssmartmovethreshold 100 100
sharedminorstart 33000 33000
reclaim_on_delete_wait_period 1 1
reclaim_on_delete_start_time 22:10 22:10
usesmartmovewithvvr on on
3. The unused disk region for any VxVM volumes. This region of space is not automatically reclaimed by default.
The user has to manually specify the "vxdisk -o full reclaim" command to reclaim this region, and this may not take a long time to complete.
VxVM CLI to reclaim storage
Volume-manager CLI to Reclaim storage
# vxdisk reclaim <
The reclaim is performed either at the diskgroup and/or 'disk' and/or 'enclosure level.
The reclaim command goes through the list of all TP lun backed mounted file system associated to the specified object, and issue the reclaim on all the file systems.
The output displays the list of volumes skipped and the list of volumes reclaimed.