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

[Fam Zheng]

On Tue, 06/02 11:28, Eric Blake wrote:
> 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 <address@hidden>
> > ---
> 
> > +++ 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).

We always skip sectors which are initially unallocated (at the time of mirror
job starting), actually this even stays true for both unmap=true and
unmap=false now.

The difference is how we handle sectors discarded *after* mirror job starts:

Before, we ignore the *discard*, which means the target remains populated, with
old data before discard.

After, we honor the discard, depending on two factors:

    source read as zero    unmap                 RESULT
==========================================================================

           Y               true       write zero with BDRV_REQ_MAY_UNMAP

           Y               false      write zero without BDRV_REQ_MAY_UNMAP

           N               both       discard (note that on some protocols
                                      this may be nop)

In other words, the unmap option only affects sector X if:

1) in the beginning, sector X was allocated
2) drive-mirror starts
3) sector X got discarded at source side

All in all, this is quite advisory.

Fam