Reclaim disk space on a 3PAR

Management of storage subsystems: SAN, volume shadowing, logical disks, file systems, and more.
Post Reply

Topic author
brunoseghers
Visitor
Posts: 1
Joined: Fri Aug 27, 2021 8:56 am
Reputation: 0
Status: Offline

Reclaim disk space on a 3PAR

Post by brunoseghers » Fri Aug 27, 2021 9:07 am

Dear all,

I would like to expose you an issue with the hope that you can help me to solve it in the best way.

We have OpenVMS 8.4 clusters connected to a full SSD 3PAR storage box via a FC SAN.

We have thin provisioning activated on the 3PAR meaning that we make some “overbooking” with the disk size. We can’t have all disks presented with 100% used space because we don’t have that physical disk space available.

The 3PAR use the free space available on each disk as a common free space pool available to ensure the used size increase of all the disks. (Don’t ask me more, I’m OpenVMS system manager, not Storage manager)

On OpenVMS, a simple DELETE doesn’t tell to the 3PAR that this deleted area is available to be part of the common pool. The 3PAR still considers that location as used.

With DELETE/ERASE, “the storage location is overwritten with a system specified pattern so that the data no longer exists.”

So, I had to implement something that will make an erase operation.

I though to put in place a SET VOLUME /ERASE_ON_DELETE but I’m afraid that severe performance decreases will occur, especially on heavy used disks (creating and deleting a lot of files).

So I made the choice of DELETE/ERASE.

Twice a week, I create 10 MB dummy files until the disk if 95% Full. Then I initiate a DELETE/ERASE of those files. The delete is made one by one to verify that something else is not busy to fill in the disk. If it is the case, I make a simple DELETE for the rest of the files which is more performant.

I don’t create a big file because the DELETE/ERASE could take many time and the size is not available during the operation. This could compromise the used space increase requested by the application.

My problem is that for big disks (800GB) with a low used space, we create thousands and thousands of files and the DELETE/ERASE takes days.

Do you see another way of working ?

I checked the defragmenter, there is a /CONSOLIDATE_FREESPACE but not a “/ERASE_FREESPACE” option

I was hoping to find something in OpenVMS that could act in background, all the time without impacting the performances.

Thanks for your help.

Seghers Bruno


hein
Contributor
Posts: 20
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: Reclaim disk space on a 3PAR

Post by hein » Mon Aug 30, 2021 3:51 pm

Many questions
- Did you test for the process create to work at all, irrespective of performance
- 10,000 block is piddly - start with a 1,000,000 at the very minimum
- Are you at least allocating contiguous-best-try or contiguous?
- If you create and then delete many files, be sure to delete then in reverse order from the delete, use short file names, use multiple versions instead of or in addition to short filenames.
Reverse delete order doesn't have to be exact, but it should be close to get better speed.
So it's ok to delete 91..100, 81..90, 71..80 but not ok to delete 1..100
Use epoch seconds timestamp as file name to make that easy, and to have a short names?
- What about fragmentation
- Why not use MOUNT or INIT /ERASE_ON_DELETE ?
- What if a program pre-zeroes a file - de-allocating the blocks at the storage level?
- What about physical disk chunks size and OpenVMS cluster size interactions? I'm sure all block in a chunk need to be zeroed but OpenVMS has probably finer grained allocation (cluster level) - back to that fragmentation question.

I doubt thin provisioning and OpenVMS are properly integrated.

Are those block initiated on initial write or on initial access, read included, and pre-zeroed on read?
OpenVMS assumes those blocks are still there and as it left them.
What if a program pre-zeroes a file, for example a (admittedly rarely used) Relative file and with that effectively de-allocates spaces for what it thought it had just allocated and cleared?

There is some chance it works with Zero detect policy enabled on the 3PAR VV level. Is it?

It would require writing all zeroes. Did you verify that the erase pattern is indeed all zeroe?
If you check the help for erase_on_delete you will "the storage location is overwritten with a system specified pattern"
It does not specify/guarantee zeros. Are they

Personally I'd look also to test some with for a private program using QIO WRITE + IO$M_ERASE (see note below)
One simple way to test this is to use a program, to create a RELATIVE file as tt will use IO$M_ERASE with zero as param.
For example:
$ create/fdl="file; org rel; allo 1234567; buck 50; rec; siz 1000;"
note: the first block will NOT be zero.

Check out this topic:

https://community.hpe.com/t5/HPE-3PAR-S ... S0pd45KiUk

hth,
Hein

Note from (old) OpenVMS IO Ref manual:
The function-dependent arguments for IO$_WRITEVBLK, IO$_WRITELBLK,
and IO$_WRITEPBLK functions that include the IO$M_ERASE function modifier
are as follows:
• P1—The starting virtual address of the buffer that contains a 4-byte, userspecified erase pattern.
If the P1 address is 0, a longword of 0 will be used for the erase pattern.
If the P1 address is nonzero, the contents of the 4 bytes starting at that address will be used as the erase pattern.
Compaq recommends that the user specify a P1 address of 0 to lower system overhead.
On OpenVMS Alpha, P1 can be a 64-bit address.
Hein: This IO function uses magic to minimize memory buffer spaces allocation and probing.

Added in 8 minutes 46 seconds:
I just noticed this topic is also posted on comp.os.vms where Volker provided a reference to a presentation Keith gave back in 2014 and is good reading with further references into 3par (although that hp.com link is likely stale).

https://www.sciinc.com/remotedba/techin ... penVMS.pdf

Hein


hein
Contributor
Posts: 20
Joined: Fri Dec 25, 2020 5:20 pm
Reputation: 0
Status: Offline

Re: Reclaim disk space on a 3PAR

Post by hein » Tue Aug 31, 2021 9:59 am

And I think this is a working link to the same "HPE 3PAR Thin Technologies" document Keith's presentation refers to:

https://learnvmware.online/wp-content/u ... 987enw.pdf


mark.jilson
VSI Expert
Visitor
Posts: 2
Joined: Wed Apr 22, 2020 10:28 am
Reputation: 0
Status: Offline

Re: Reclaim disk space on a 3PAR

Post by mark.jilson » Tue Aug 31, 2021 10:33 am

VSI does not support the Reclaim feature.

Excerpts from Jan 2019 Support Bulletin

HPE OpenVMS RECLAIM feature
HPE introduced a reclaim feature in the HPE patch kit VMS84I_SYS-V0700, item 5.1 to further support
thin provisioned volumes. This feature is enabled by the INITIALIZE/RECLAIM and SET
VOLUME/RECLAIM commands. Refer to the VMS84I_SYS-V0700 Release Notes for the complete
documentation.

VSI OpenVMS does not support RECLAIM
VSI has evaluated the HPE implementation and at this time, VSI has chosen not to include the RECLAIM
feature in any VSI OpenVMS version.

Post Reply