
* Docs: Replace instances of pvc with storage All instances of DataVolume > Spec > PVC have been replaced with storage, except for two cases in datavolumes.md: - Data Volumes>Target Storage/PVC>PVC https://github.com/kubevirt/containerized-data-importer/blob/338bafe/doc/datavolumes.md#pvc - Data Volumes>Source>PVC source https://github.com/kubevirt/containerized-data-importer/blob/338bafe/doc/datavolumes.md#pvc-source Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Docs: Replace `Storage` with `storage` in doc/datavolumes.md I also reworded it so that the paragraph does not start in lower-case. Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Docs: Remove optional default 'accessModes: ReadWriteOnce' from docs Removed from storage options, I still kept it for the pvc. Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Docs: Remove resources/requests/storage when cloning a PVC This argument is optional. Only removed for 'storage', not 'pvc'. Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Replace 'pvc' with 'storage' API in manifests Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Docs: Moved 'Target Storage/PVC' section above 'Source' Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Docs: Rephrase the Storage target section to emphasize it over PVC Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Fix empty field in YAML file Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Rephrase prose around filesystem volume mode Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Fix grammar and spelling Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Write acces mode in upgrade-testing-artifacts manifest Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> * Update doc/datavolumes.md Co-authored-by: Alexander Wels <awels@redhat.com> Signed-off-by: Edu Gómez Escandell <edu1997xyz@gmail.com> --------- Signed-off-by: Edu Gómez Escandell <egomez@redhat.com> Signed-off-by: Edu Gómez Escandell <edu1997xyz@gmail.com> Co-authored-by: Alexander Wels <awels@redhat.com>
1.9 KiB
Data Volume preallocation
Introduction
In order to improve write performance, QEMU provides the ability to preallocate image files, used as backing for DataVolumes.
There are several methods for preallocation. CDI uses the best one available, depending on the
underlying file system and device type. It tries to use the OS's fallocate
call if the filesystem
supports it and falls back to "full" preallocation for block devices. Preallocation does not depend
on the source of the DV, i.e. it can be used for import, upload or blank DVs.
See qemu-img
documentation to learn
more about preallocation. See also below for considerations regarding different datavolume types.
Preallocation for a DataVolume
To preallocate space for a DataVolume, use preallocation
field in DataVolume's spec:
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
name: preallocated-datavolume
spec:
source:
...
storage:
...
preallocation: true
Enabling preallocation globally
Preallocation can be also turned on for all DataVolumes with an entry in the spec.config
of the CDI
resource:
kubectl patch cdis.cdi.kubevirt.io cdi -p '{"spec": { "config": { "preallocation": true }}}' -o json --type merge
If not specified, the preallocation
option defaults to false.
Considerations
Preallocation can be used in the following cases:
- import (any source)
- upload
- cloning
- blank images
- blank block data images.
However, different DataVolume types use different preallocation methods:
- for blank block devices: the space is filled with zeros.
- for cloning volumes: handling sparse files is turned off, so the destination volume is filled in full, even if the source volume is not preallocated.
- blank images, upload and import volumes use qemu-img preallocation option, using
falloc
if available, andfull
otherwise.