3PAR volumes showing max utilisation yet same LUNs presented to OpenVMS blade showing 50% free

[Paolo_c]

We recently configured some new 3par storage for some OpenVMS blades running OpenVMS 8.4.  The issue we have is that on the VMS blades the disk space is showing the correct utilsation (with most disks showing at least 50% free blocks),  but on the 3par,  the equivalent virtual volumes are showing 100% capacity utilization (total used /host written) and wondering if there are any commands that can be run on the 3Par to reset the volumes to display the correct disk utilisation. 

I suspect that at some point the disks on the VMS system must have reached near saturation level , but despite reclaiming disk space under OpenVMS, the 3Pars are still showing the max level utilisation reached (rather than the current utilisation ). 

p.s I previously (mistakenly) posted this issue under the OpenVMS messageboard so hoping that  this post yields a better response

[Sheldon Smith]

I can only assume the virtual volumes are in fact, thinly provisioned.
In VMS, show volume /full to see the current settings. You need to first set the volumes for Erase on Delete. And the VMS host is still using the default erase pattern. Next, you will need to make several Very Large files (copy nl: /alloc={big-number} ...) to fill up most of the volumes' free space, then with the volumes' Erase on Delete already set, delete those files.

Initialize any future volumes with /erase=delete. (Wow: It's been quite a while since I did anything with VMS.   )

See the HPE 3PAR Storage Adaptive Data Reduction Technologies 

[Paolo_c]

Hi Sheldon, 

I can confirm the volumes are thinly provisioned. WIth regards to the workaround you suggested. We are not in a position to reinitialise these volumes /erase_on_delete (as have either gone or about to go live on the associated systems), As a workaround test (which hopefully will serve us a solution going forward). I changed a couple of our exisitng drives to /erase_on_delete using the $set volume/erase command.  Following your instructions I then created some very large files using the copy nl: /alloc=xxxx command .Although I was able to create the files okay, when I attempted to delete them nothing happended (or rather my sesssion hung). which left me with having to shutdown the server via the ILO ,  boot Server min_vms startup, mount the drive /over=id and then delete the file (which worked okay but wasnt an ideal workaround). 

I then retried the operation, but this time by copying large existing files to 2 drives (the 1st drive showing 0% at both the VMS 3par level and the other showing 29% at the VMS level and 99% at the 3par level.). The copy/delete for the 1st drive yielded the correct results in that the 3par showed 50% utilisation after copying 25 gb file (to 50gb drive), and then reverted  back to 0% utilisation post deletion of file. The 2nd drive yielded slightly different results (which i guess is to be expected given that disk was already 30% full prior to changing volume to /erase_on_delete.  I copied several 25gb files  to the drive and utilisation at the 3par level changed to 97% (and at the VMS level from 29%- 44%). however post deletion , vms returned to 29% but at the 3par is now showing 77% (693.70gb used, in place of the original 899gb ! - so assuming that if were to completely the saturate the drive and then delte the files, the values at the 3par level, should show further reduction in disk utilisation.   

The issue that concerns me tje most about applying the set volume/erase command as a solution to this issue, is the amount of time it takes to delete files using the erase option, (took approx 30 mins to delete 150gb files). We have numerous  procedures /incl backups which perform deletes (inc some large files, and so fairly concerned that this could have a detrimental impact on performance going forward (albeit with the benefit of knowing that the utilisation on the 3par level wont; exceed current constraints )

[Sheldon Smith · Accepted solution]

(It has been well over a decade since I supported VMS. :)  )

For the existing volumes, you just need to Set Volume /erase. Any new volumes would be Init /erase.

As far as I know, VMS has never added the UNMAP action; erasures send the system erase pattern (defaulting to NUL bytes) to the file before releasing the storage. While the 3PAR ASIC will handle the received NULs immediately, the VMS host does need to write them all to get them to the 3PAR.

No idea why deleting the files created with Copy NL: would have hung the system. Unless they were Very Large, and your process was tied up writing all those NULs. Probably better suited for a batch job: With a parameter of "how full", get the volume's current free space size, have a loop that makes a number of junk files that total how full you want the file system to get, then delete /log the junk files. The batch log should show where it's at while deleting the junk files.

Assuming your backup procedures do any deletions toward the end, it would tie up the batch job until done, but at least it's not someone's interactive process.

[Paolo_c]

Many thanks for the feedback provided. I am now looking to apply this as solution to the ThP issue.. Although I was aware of the delete/erase command before we'd never had any reason to apply the setting at the volume level before, as previously all of our ThP storage was presented from an XP24000 and XP7 SAN's  (and never had any issues /disparity with disk space before)..