Trident allocating too much storage (10%) for LUN metadata

[yaeladsl]

Describe the bug
When creating PVCs in Kubernetes, a volume is created in Ontap based on the following calulation:
Total volume size = [(PVC request size)/(1 -(snapshotReserve percentage)/100) * 1.1
Based on this calculation, when snapshotReserve=0, the volume size in Ontap is always 10% larger than the useable storage in Kubernetes.
This means that if I create a 6TB PVC, I will be able to use 6TB, but the allocated space in Ontap will be 6.6TB (600GB for LUN metadata). In an HA cluster, maybe even 1.2TB will be used for LUN metadata.
This seams unreasonable.
The calculation is taken from the following KB:
https://docs.netapp.com/us-en/trident/trident-use/ontap-san-examples.html#backend-configuration-options
I was asked by NetApp support to open an issue here, since they weren't able to help me.

Environment
Provide accurate information about the environment to help us reproduce the issue.

• Trident version: 22.10
• Trident installation flags used: "storageDriverName": "ontap-san","spaceReserve": "volume",
• Container runtime: containerd://1.6.9
• Kubernetes version: v1.25.6
• Kubernetes orchestrator: Kubernetes
• OS: Rocky Linux 9.3
• NetApp backend types: Ontap Select 9.8P19, two node cluster (1 HA Pair)

To Reproduce
Create a pvc. For example a 100GB PVC. Can be created from the example in the trident installation folder under: sample-input/pvc-samples/iscsi-pvc-basic.yaml
In Kubernetes, the PVC and PV will appear as 100GB. In Ontap, the LUN will appear 100GB and the volume will appear as 110GB.

Expected behavior
The larger the LUN will be, the smaller the percentage of extra space allocated for LUN metadata.

Additional context
N/A

[wonderland]

Not to diminish the request in any way, but just for additional clarity: Unless you explicitly configure it otherwise, everything will be thin provisioned. So none of that extra space is actually used/taken, the volume size is just a number that specifies the upper limit.

[yaeladsl]

Not to diminish the request in any way, but just for additional clarity: Unless you explicitly configure it otherwise, everything will be thin provisioned. So none of that extra space is actually used/taken, the volume size is just a number that specifies the upper limit.

Thanks for your comment.
Are you sure about that? I'm not sure this is the case when using Thick provision for the volumes themselves as we do in our environment. Although, even if it's thin provision, it has the capability to use 10% and then we will be over provisioned...

Our problem is that we purchased a license for the specific amount of storage and since this is a production environment, we preferred using thick provision. We were not able to create all the volumes due to insufficient storage, regardless of our calculation (Which of course didn't take into consideration the 10%)
So either something else is consuming this storage, or the LUN metadata is thick provision.

[wonderland]

See https://docs.netapp.com/us-en/trident/trident-use/ontap-san-examples.html#backend-configuration-options-for-provisioning-volumes

• spaceAllocation --> This is for the LUN itself, by default "true" so the LUN space is reserved (e.g. the actual size of your PVC)
• spaceReserve --> This is for the underlying volume, by default "none" so the space of the volume (which is 1.1 times the size of the PVC) is thin provisioned

Not sure at which value your license enforcement is looking, might be provisioned capacity, in which case I understand the pain.