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 <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).
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
