reclaim_on_delete_start_time only allows 22:00-03:59

[AAlmroth]

Hi all,

I'm trying to force a reclaim of thin provisioned storage, by altering the vxtune variables;

reclaim_on_delete_start_time

reclaim_on_delete_wait_period

As I already deleted the volumes, and with the 1 day delay, I wanted to speed up the process somewhat.

So I changed reclaim_on_delete_wait_period to -1. Fine for new deletion it should kick in immediately, right?

Next, for the already deleted volumes, I wanted to change the start time, but in conctradiction to the manual, I cannot change to any time of the day.

It only allows 20:00-03:59. All other values ends up with an error.

I'm on SFRAC 6.1, on RHEL6.3. I can't really test on any other platform, but is this a common problem, or just my install, or platform? Are there any other ways of forcing a reclaim?

/A

[Gaurav_S · Accepted solution]

As per guide, -1 to 366 should be an accepted value . I would recommend to open a support case here for Symantec to analyze

Storage that is no longer in use, needs to be reclaimed by the array. The process of reclaiming storage on an array can be intense on the array. To avoid any impact on regular I/O's to the array, the reclaim operation is made asynchronous. When a volume is deleted the space previously used by the volume is tracked for later asynchronous reclamation. This asynchronous reclamation is handled by vxrelocd (or recovery) daemon.

To perform the reclaim operation during less critical time of the system can be controlled by the following two tunables reclaim_on_delete_wait_period andreclaim_on_delete_start_time.

The default value for these tunables are:

reclaim_on_delete_wait_period=1 
reclaim_on_delete_start_time=22:00

reclaim_on_delete_wait_period

The storage space used by the deleted volume is reclaimed after reclaim_on_delete_wait_period days. The value of the tunable can be anything between -1 to 367. The default is set to 1, that means the volume is deleted the next day. The storage is reclaimed immediately if the value is -1. The storage space is not reclaimed automatically, if the value is greater than 366. It can only be reclaimed manually using vxdisk reclaim command.

[rsharma1 · Accepted solution]

Yes with reclaim_on_delete_wait_period set to -1 the reclaim should be trigerred immediately. Do you notice any messages for a reclaim task (trigerred after a new deletion) in /etc/vx/log/reclaim_log ? What array is being used here? Regarding not being able to set the start_time beyond the window you mentioned, this seems like a bug and you may want to open a support case.

[AAlmroth]

Thanks for your responses. After five days, the volumes are now reclaimed. I haven't looked into the logs when the commands were started, but for 10TB I wouldn't expect as long as five days.

Anyhow, that is not the important point, I still think it is a disconnect between documentation and actual behavour in regards to when reclaimation can be started. In my original post:

"Next, for the already deleted volumes, I wanted to change the start time, but in conctradiction to the manual, I cannot change to any time of the day.

It only allows 20:00-03:59. All other values ends up with an error."

The documentation states I can provide any time of the day, but any other values than between 20:00 and 03:59 ends with an error.

Perhaps a candidate for a change in behavour or change to documentation?

/A

[rsharma1]

The behavior you mentioned has been corrected (should be available in the forthcoming patch).