On 05/27/2015 11:29 PM, Fam Zheng wrote: > If specified as "true", it allows discarding on target sectors where source is > not allocated. > > Signed-off-by: Fam Zheng <f...@redhat.com> > ---
> +++ b/qapi/block-core.json > @@ -954,6 +954,11 @@ > # @on-target-error: #optional the action to take on an error on the target, > # default 'report' (no limitations, since this applies to > # a different block device than @device). > +# @unmap: #optional Whether to try to unmap target sectors where source has > +# only zero. If true, and target unallocated sectors will read as > zero, > +# target image sectors will be unmapped; otherwise, zeroes will be > +# written. Both will result in identical contents. > +# Default is true. (Since 2.4) Just making sure I understand: The guest sees identical contents, but with "unmap":true, the host file is potentially sparse, while with "unmap":false, the host file is fully-allocated. Also, while the default is now true, this doesn't tell me what the behavior was in 2.3. Is this a new default behavior (where in 2.3 you could not preserve sparseness), or a new knob (previously you always got a sparse copy, and could not request full allocation)? I'm okay either way, but I'm trying to understand whether libvirt should advertise this knob to higher-level apps, and if so, what libvirt should do when it detects qemu 2.3 (that is, should it tell upper-level apps that sparseness cannot be preserved, or that full allocation cannot be guaranteed, when the "unmap" parameter is not detected). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
