InfoScale 7.1: Automatic thin reclamation does not work when tunable reclaim_on_delete_wait_period is set to -1

book

Article ID: 100048836

calendar_today

Updated On:

Description

Error Message


The below output displays the thin space to be reclaimed:

Sample output

# vxdisk -o thin list
DEVICE SIZE(MB) PHYS_ALLOC(MB) GROUP TYPE RECLAIM_CMD
svm_san20_3 204800 0 dgora1 thinrclm WRITE_SAME
svm_san20_5 15360 0 dgora2 thinrclm WRITE_SAME

When reviewing the reclaim_log file, no entries are seen regarding automatic thin reclaim events until a manual vxdisk reclaim command is started.

# tail -16 /var/adm/vx/reclaim_log


When running a manual reclaim command:

#PPID : 32514 PID : 20349
cmd : /sbin/vxdisk -o full reclaim dgoraimes
node : fred
START_TIME DURATION(s) DISKGROUP VOLUME DISK SUBDISK OFFSET LEN PA_BEFORE PA_AFTER TYPE STATUS
2020_10_28 13:53:20 11 - - dgora1 - 314562816 104851104 0 0 gap reclaimed

#PPID : 26621 PID : 29652
cmd : /sbin/vxdisk -o thin reclaim vg_no_mon
node : fred
START_TIME DURATION(s) DISKGROUP VOLUME DISK SUBDISK OFFSET LEN PA_BEFORE PA_AFTER TYPE STATUS
2020_11_02 10:56:58 2 dgora2 svm_san20_5 svm_san20_5-01 65792 31389696 0 0 vxfs reclaimed


[VxVM][201028-001233][APA IT INFORMATIONS TECHNOLOGIE GMBH] RHEL 7.4 7.1.0.300: Thin reclaim NOT happening automatically for thinrclm enabled disks (Netapp-AFF Storage System) even with reclaim_on_delete_wait_period=-1 set


https://jira.community.veritas.com/browse/STESC-5177

Cause

 

The event required to process the automatic thin reclaim activity is not being generated for vxnotify to action when the tunable  "reclaim_on_delete_wait_period" value is changed from the default setting. This results in vxnotify sleeping and taking no action to automatically reclaim the required thin space. 

This is a known issue with InfoScale 7.1 : etrack 3879516
 
The defect prevents the automatic reclaims event(s) being triggered and no action being taken.

Resolution


The issue exists in InfoScale 7.1.x and is fixed in InfoScale 7.2 and higher. Customers are advised to upgrade to InfoScale 7.2 or higher.


Workaround:

The thin space can still be reclaimed manually by running VxVM command:

# 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.


 

Issue/Introduction


By default, the vxrelocd daemon runs everyday at 22:10 hours and reclaims storage on the deleted volume that are 1 day old.


# /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


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.

If vxrelocd daemon is not running, then it can be manually started by typing /usr/lib/vxvm/bin/vxrelocd &.
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.
Specified as an integer from -1 to 366, where -1 specifies immediately and 366 specifies never.
With InfoScale 7.1.x automatic thin reclamation is not happening even when the reclaim_on_delete_wait_period tunable is set to -1. Even though vxrelocd is checking the tunable value, no automatic action is being taken to reclaim the available thin space, however, manual vxdisk reclaim operations do still work.