VSI OpenVMS Forum

An interesting question on behalf...

https://docs.vmssoftware.com/vsi-openvm ... ase-notes/

> With regard to the release notes, do you understand this restriction?
>
> 1.1.1. VSI OpenVMS Does Not Support Thin-Provisioned Volumes on
> Any Architecture
>
> I understand "Thin provisoning" to be that when an OpenVMS tries to
> define a disk with a certain size, that the virtualizing platform does
> not initially reserve all the space defined, but only for the blocks
> that are occupied. When the space grows the virtualization SW will map
> more physical storage.
>
> With "thick provisioning" all the physical space is pre-allocated,
> whether an Operating System uses it or not.
>
> What does an Operating System have to do to be able to support "Thin
> provisioning"?
>
> Does a virtualizing environment VMware/KVM not act like an intelligent
> storage solution?
> ie. it is all transparent for the Operating System?

I've expecting that statement and was wondering when it would appear.

I've found that thin provisioned virtual volumes provided by 3PAR work with OpenVMS V8.4-2L1 i64 however the performance can be worse than with full provisioned. I've mostly converted the virtual volumes to full provisioning and this gives me a push to finish that. I've not seen any loss or corruption of data.

I've not tried thin provisioned volumes on OpenVMS x86 V9.x.

I am not a HW person, but I would expect a write where the VM software has to allocate new space before completing the write to be many times slower than a normal write, and maybe there could be a timeout issue.

I'm intrigued why VSI don't support thin provisioned volumes but HPE did.

imiller wrote: ↑

Tue Jan 30, 2024 5:15 am

I'm intrigued why VSI don't support thin provisioned volumes but HPE did.

Only VSI knows for sure, but the decision could simply be financially motivated:
Support costs associated with not supporting a feature/capability: near zero
Support costs associated with supporting a feature/capability: non-zero

You have to make the latter work, test it, listen to customer complaints, answer support questions, improve it, document it.
For the former, you just have to add a paragraph to the release notes.

Every company, VSI included, has to prioritize where they want to invest resources.

To support Thin Provisioning, the device driver and the OS needs to support the TRIM (ATA) or UNMAP (SCSI) commands. Theses commands release unused LBNs back to the storage device when a file is deleted. It could be done but involves changes to the driver and the file system, etc.

Paul A. Jacobi
VMS Software.

pjacobi wrote: ↑

Tue Jan 30, 2024 5:15 pm

To support Thin Provisioning, the device driver and the OS needs to support the TRIM (ATA) or UNMAP (SCSI) commands. Theses commands release unused LBNs back to the storage device when a file is deleted. It could be done but involves changes to the driver and the file system, etc.

Paul A. Jacobi
VMS Software.

Thank you Paul. Authoritative is always preferable.

Still not clear to me how that explains "loss or corruption of data on the device" in the release notes.

The lack of this support also affects "Thick provisioned" devices with the effect that possible freed blocks are not released(?).

Or am I missing something?

VSI OpenVMS does not support thin-provisioned volumes on any architecture.

That appears to include OpenVMS V8.4-2L1 on I64 but I don't recall a similar statement in the release notes for that version.

HPE implemented the trimming part of thin provisioning in response to a customer request; that support appeared in a patch to HPE VMS V8.4.

The implementation was not good; the performance was so bad the customer never actually used the feature.

I took a look at the work HPE did, and decided we (VSI) should not accept that change in the VSI sources.

It was a pretty large change, in that it touched not only the SCSI class driver DKDRIVER, but also the code that implements MOUNT, INIT, DELETE, several SHOW commands, $GETDVI, the STARLET and LIB libraries, and a few other places that I cannot remember off the top of my head.

-- Rob