The fs overhead calculation is wrong for smaller images.

[awels]

What happened:
When creating a DataVolume on a ceph-rbd RWO filesystem volume, for small sizes, the created disk.img does not match the requested size even though the volume is large enough to hold it. I found this while working on an issue in KubeVirt where we create a blank 512Mi fs rwo volume.
What I observed was that the disk.img size reported by qemu-img info was about 506Mi instead of the 512Mi requested, while the actual FS volume was 540Mi, which left enough space for the 512Mi on the volume.

What you expected to happen:
I expect the disk.img size reported by qemu-img to ALWAYS be the requested size from the PVC and not be smaller in this scenario.

How to reproduce it (as minimally and precisely as possible):

• Create a blank DV using the storage field and specify you want filesystem and RWO on a ceph-rbd storage class. Also specify the size to be 512Mi.
• Let CDI finish creating the PVC and populating it.
• Create a pod that uses the created PVC (use the cdi-import container image so you get qemu-img). And run qemu-img info on the disk.img file. You will notice it is < 512Mi

Additional context:
Add any other context about the problem here.

Environment:

• CDI version (use kubectl get deployments cdi-deployment -o yaml): 1.64.0
• Kubernetes version (use kubectl version): 1.34
• DV specification: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Others: N/A

[akalenyu]

This is actually an issue we hit before, particularly common with block providers that put a filesystem on top
(and especially worse with XFS):
kubernetes/website#50146
So the calculation is correct, the request is not satisfied by the provider.

I think we could tackle this in CDI by simply whacking the internal overhead
(nothing stops user from writing out entire PVC)
This was the original form in which filesystem overhead was introduced in the first place:
#1319

I admit I am not too confident about the consequences of that, though I am also not sure if that was the motivation for the original implementation. We've had a lot of discussions about this in https://issues.redhat.com/browse/CNV-57592 and I was starting to convince myself, but I think the provider started allowing Block RWX which made filesystem volumes less desirable.

[akalenyu]

Will try to discuss this at length today in the sig-storage call but essentially this is what fs overhead looks like

So a few options we have is:

• Trust specific fs implementations (root reserve ext4 but it's disabled in the CSI utils)
• Circumvent further internal overhead reservation after reaching user disk request size (may put us in same dangers, somewhat of a FAFO)
• Distinguish inflation % from internal overhead % (disgusting bloat of API)
• Chase CSI drivers about not satisfying the user request (compensating for fs overhead is hard for them too, especially XFS)

[akalenyu]

• Circumvent further internal overhead reservation after reaching user disk request size (may put us in same dangers, somewhat of a FAFO)

We might as well just stop reserving anything (storage API, PVC API has to be distinguished) but the worry is that could bring up the same issues #1319 tried to tackle. This is the conclusion from the sig-storage meeting.