On block devices thin provisioning requires either defining the LUNs as sparse on the storage array (transparent to Vdsm) or using Vdsm’s Thin provisioning mechanism and formatting the volume with qcow2. “Preallocation” is achieved by writing zeros to the file right after creating it which does not guarantee preallocation when using smart storage (compression / dedup would cause the zeros not to be written to disk and not to allocate the actual disk space). On file based storage domains, files thinly provisioned by design (the file system provides this). Has the advantage of saving on disk space, but can cause defragmentation and have performance implications (not an issue on SSDs).
allocate as you go (a.k.a sparse/thin provisioning) - similar to files in any modern file system, storage is allocated as data is being written to the file.This, however, comes at the cost of needing to dedicate all the potential disk space ahead of time, which is wasteful. allocate everything ahead of time (a.k.a preallocated) - has the benefit of having the storage blocks contiguous which can improve performance and does not require any layer that would translate logical to physical offsets (again, can be a performance improvement).When creating a virtual disk there are normally two ways of allocating the storage blocks needed to store the data that will reside on the virtual disk. Using qcow2 provides the ability to create snapshots as well avoid having to allocate all the storage ahead of time due to the fact that qcow2 writes linearly on disk.
VDSM currently supports “raw” - offsets are mapped directly from guest FS to disk and “qcow2” which provides a logical mapping between blocks in guest and blocks on disk. This might not actually preallocate on some file systems.Ī Virtual disk can be stored on disk using different formats. * Preallocating on file domains will cause Vdsm to write zeroes to the file.
0 kommentar(er)
