Re: [Qemu-devel] [PATCH v6 2/8] qmp: Add optional bool "unmap" to drive-mirror

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

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 <famz@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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]