reclaim raw capacity on 3PAR

[Paolo_c]

Our 3PAR was showing a disparity between used capacity on some of the disks on one of our VMS hosts and the 3PAR which was due to the fact that zero blocks were not being written to disk when files were being deleted. The solution was to implement disk_on_erase capability using set volume/erase across all volumes and then fill up disk space: on existing volumes by copying large file copy /alloc=xxxx nl: $1$dga:[000000]x.x;   to fill up free space (prior to deleting it) which forced 3PAR to intercept the blocks of zero's being and trigger the reclamation of space. 

Although this action resulted in corresponding  3PAR host vv's displaying correct disk usage the overall RAW used capacity for pool remains unchanged and so wondering whether a Tune system should be run to refresh the raw capacity and if so whether it is safe to run this whilst live users are actively reading/writing data to some of the associated VV's on that 3PAR . Having said that we dont really have an quiescent points but before we initiate the tune just want to be certain that this will reclaim the usage that currently is only reflected at the VV level.

[Paolo_c]

re: my post above. Could someone please advise whether running a tunesys on the 3PAR will help reclaim the raw usage that is currently only reflected at the VV level (reclaimed 1.5 TB at VV level but has not permeated through to overall raw usage stats for the storage pool) and if so whether its safe to run tunesys this whilst live hosts are connected ?

[Paolo_c]

Given the no of people that have read this post I was hoping that someone would have experienced a similar VV's vs Raw usage capacity (RAW) GB disparity but guess I'll have to contact HP directly 

[SUBHAJIT KHANBARMAN_1]

your 3PAR VVs presented to VMWare Host or Windows Host or Linux Host?

What is the  used size or data size showing of the same VV at the Host end?

Is it matching with 3PAR end VV used size?

If I assume that space reclaim initiated properly at the Host end which means deleted space were filled with zeros and if in 3PAR VV level Zero detect policy is already enabled then VV size at the Host end and 3PAR end must be same by now.

There is something called VV reserved space which will get reclaimed slowly and these details you can find in Thin Technology whitepaper as below,

https://h20195.www2.hpe.com/v2/Getdocument.aspx?docname=4aa3-8987enw&skiphtml=1

Also you need to execute Compactcpg on the CPG from where VV got created and that will finally help to reclaim back space which will reflect in raw space increase.

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

***********************************************************************************

[Paolo_c]

Hi Subhajit,

Many thanks for the feedback provided. Please see my responses below. 

your 3PAR VVs presented to VMWare Host or Windows Host or Linux Host?  <-- OpenVMS host

What is the  used size or data size showing of the same VV at the Host end?  <-- (multiple VV's involved - see below)

Is it matching with 3PAR end VV used size?    <-- yes the 3PAR end VV used size now matches VV used size at the Host end (I applied the documented $ set volume/erase_on_delete volume_name on the host end , followed by $copy/alloc=xxxxx (free blocks on destination disk) $1$dxx:[000000]x.x; to fill up disks , $delete/erase $1$dxx:[000000]x.x; to force 3PAR to intercept the blocks of zero's and trigger reclamation of space. The used space on VV's on 3PAR now match used space on VV's on host end but the allocated capacity (block & system) as shown under SSMC >dashboard > system (KG_UK1_3PAR_8200_01) capacity still showing original allocation and was wondering originally whether running  a tunesys would reclaim this allocation but note your suggestion below to execute compactcpg on the CPG from where the VV's got created . Do you know whether this is safe to run during the working day (whilst live hosts are connected/actively reading /writing to the associated VV's ?) 

p.s I have a file containing screenshots of the associated used space by disk reports (user raw reserved space) and SSMC capacity usage etc but cannot see an option which allows me to attach it to this post. 

Regards

Paul 

If I assume that space reclaim initiated properly at the Host end which means deleted space were filled with zeros and if in 3PAR VV level Zero detect policy is already enabled then VV size at the Host end and 3PAR end must be same by now.

There is something called VV reserved space which will get reclaimed slowly and these details you can find in Thin Technology whitepaper as below,

https://h20195.www2.hpe.com/v2/Getdocument.aspx?docname=4aa3-8987enw&skiphtml=1

Also you need to execute Compactcpg on the CPG from where VV got created and that will finally help to reclaim back space which will reflect in raw space increase.

[SUBHAJIT KHANBARMAN_1 · Accepted solution]

It's better to run compactcpg in Out of Business hours. 

Tunesys just rebalance chunklet distribuation accross the system. It will never help to reclaim space.

Please find some details which is old information but useful to know,

***********************************************************************************************************************************************

Thin Persistence reclamation

Thin Persistence reclamation occurs at several levels. Initially all freed 16 KiB pages are returned to the TPVV. This means that on a file system that supports automatic reclaim the spaced freed by an UNMAP after a file deletion is immediately available for reuse by a file creation or file extension operation on the same file system.

To make space available for reuse by other volumes, there is a reclaim thread that returns freed 128 MiB regions allocated to a TPVV back to the CPG. This thread scans volumes every five minutes for SD space that potentially can be reclaimed. If a TPVV has free 128 MiB regions or there is enough free space to warrant a defragmentation of the volume then space will be reclaimed back to the CPG. Defragmentation occurs if there is more than 1 GB of available space to reclaim and results in free 128 MiB regions. Up to 16 volumes at a time can be queued for reclaim processing.

How quickly the space is reclaimed depends on a number of factors. If there is a large amount of freed space on a volume, then this may not be processed within a single reclaim period and once the reclaim process runs on a TPVV, the reclaim process will not run again on that TPVV again for at least 90 minutes. Therefore, large space reclaims can take several hours to complete.

In addition, the reclamation on a TPVV can be deferred for various reasons.

For example, if the SD space of a TPVV is grown, then reclaims on the volume will be deferred for 60 minutes. Also, if reclaim is de-fragmenting a TPVV and the defragmentation does not complete during the reclaim interval further reclaim will be deferred for 8 hours.

Thin Persistence reclamation may not reclaim all the free space on a volume. There is a 4 GB per node threshold below which the TPVV will not be inspected for available 128 MiB regions that can be reclaimed back to the CPG. The free space will still be available for reuse by the TPVV. Those new to Thin Provisioning often like to verify Thin Persistence reclamation by creating a test scenario of filling a file system then deleting the files and running a space reclamation tool. It is important to understand that the space will not be returned to the CPG immediately. The showvv –s command will show how much space has been allocated to the TPVV and the difference between the space in use and the reserved space shows the amount of space reclaimed for use within the TPVV. The amount of reserved space will decrease over time as the space is reclaimed back to the CPG in the background by the reclaim thread.

**********************************************************************************************************************************************

Hope this helps!
Regards
Subhajit

I am an HPE employee

If you feel this was helpful please click the KUDOS! thumb below!

**********************************************************************************

[Paolo_c]

many thanks for all the feedback you've provided. I wil now look to schedule this task accordingly