On 1/9/19 10:51 AM, Kevin Wolf wrote: > Am 09.01.2019 um 17:42 hat Paolo Bonzini geschrieben: >> On 09/01/19 12:23, Kevin Wolf wrote: >>> Also note that this is only metadata preallocation; full preallocation >>> will still return allocated for the protocol layer and so it will always >>> be slow. >> >> Full preallocation these days can create images with preallocated but >> known-zero blocks, I think? > > That would defeat one of the main purposes of preallocation because it > would still require COW and metadata updates on the first write. > > If there is demand, we could add something like preallocation=data where > data clusters are preallocated but COW/metadata updates still happen at > runtime, but so far nobody has asked for it. Not sure when you would use > it either.
Except there HAS been talk about it before - such a mode makes it so that you can guarantee a non-fragmented image, or even guarantee that the entire guest-visible portion is contiguous and all qcow2 metadata is at the front or back of the overall qcow2 file, making it very easy to convert between qcow2 -> raw (strip the qcow2 metadata) or go in reverse (wrap a raw into a qcow2) without having to shuffle the guest-visible portions of the file. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
