From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z02sC-00006h-TZ for qemu-devel@nongnu.org; Wed, 03 Jun 2015 03:14:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z02sB-0006q1-St for qemu-devel@nongnu.org; Wed, 03 Jun 2015 03:14:00 -0400 Date: Wed, 3 Jun 2015 15:13:48 +0800 From: Fam Zheng Message-ID: <20150603071348.GF1533@ad.nay.redhat.com> References: <1432790990-25383-1-git-send-email-famz@redhat.com> <1432790990-25383-3-git-send-email-famz@redhat.com> <556DE7B2.8020405@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556DE7B2.8020405@redhat.com> Subject: Re: [Qemu-devel] [PATCH v6 2/8] qmp: Add optional bool "unmap" to drive-mirror List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , qemu-block@nongnu.org, Jeff Cody , qemu-devel@nongnu.org, qemu-stable@nongnu.org, Stefan Hajnoczi , pbonzini@redhat.com, jsnow@redhat.com, wangxiaolong@ucloud.cn 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 > > --- > > > +++ 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