Repository navigation
doc: explain how filesystem overhead changes PVC and image size - #4318
Conversation
The DataVolume docs say that with `spec.storage` CDI requests "a PVC big enough to fit both an image and the file system metadata", and the CDI config docs describe filesystemOverhead as the share of a Filesystem volume to reserve. Neither says what size the PVC and the disk image end up with, so it is easy to read the requested size as the PVC size and expect a guest disk that is about 6% smaller, or the other way around. Since kubevirt#3779 the math is: - PVC request = align(size, 1MiB) * (1 + overhead) (GetRequiredSpace) - image size = min(free space, PVC request) / (1 + overhead), rounded down to 1MiB (GetUsableSpace) Document this with a worked example (10Gi -> 11381663335 bytes, image of 10Gi), and note that with `spec.pvc` the PVC is not inflated but the overhead is still reserved, so the image comes out smaller than the request. Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: YoungjuKim <[email protected]>
kubevirt-prow
Bot
added
release-note-none
|
Hi @fjvbn2003. Thanks for your PR. PRs from untrusted users cannot be marked as trusted with I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: awels The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
kubevirt-prow
Bot
added
the
approved
|
coverage: 50.286% (+0.07%) from 50.213% — fjvbn2003:doc-fs-overhead-sizes into kubevirt:main |
|
/override pull-containerized-data-importer-e2e-ceph |
|
@awels: Overrode contexts on behalf of awels: pull-containerized-data-importer-e2e-ceph DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
What this PR does / why we need it:
doc/datavolumes.mdsays that withspec.storageCDI requests "a PVC big enough to fit both an image and the file system metadata", anddoc/cdi-config.mddescribesfilesystemOverheadas the share of a Filesystem volume to reserve. Neither page says what size the PVC and the disk image end up with. We sized VM root disks from these pages and expected a 10Gi request to give the guest about 9.4GiB. Withspec.storagethe guest disk is the full 10Gi, and the PVC is the one that grows.Since #3779 the math is:
align(size, 1MiB) * (1 + overhead)(GetRequiredSpace)min(free space, PVC request) / (1 + overhead), rounded down to 1MiB (calculateTargetSize,GetUsableSpace)Checked on CDI v1.66.0 with the default overhead (
0.06) on an NFS storage class (filesystem mode):spec.storagerequestFor the 10Gi volume,
qemu-img infoin the virt-launcher pod reportsvirtual size: 10 GiB (10737418240 bytes)fordisk.img.This PR adds the formula and the worked example to both pages, says that with
spec.pvcthe PVC is not inflated but the overhead is still reserved inside it (so the image comes out smaller than the request), and links #4024 for the case where the provisioned filesystem has less free space than requested.Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Docs only. The
spec.pvcsentence is based on the code paths above (import, upload and blank all size the image withGetUsableSpace); I did not measure that case.Release note:
This change was drafted with AI assistance and reviewed by me.
🤖 Generated with Claude Code