From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhJu1-0000I9-29 for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:06:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhJu0-0000bO-93 for qemu-devel@nongnu.org; Wed, 30 Sep 2015 12:06:44 -0400 References: <56094B0F.7030900@redhat.com> <5609A38F.1070405@redhat.com> <20150929081034.GA3930@noname.str.redhat.com> <560A4F0A.50005@redhat.com> <20150929093531.GD3930@noname.str.redhat.com> <560A6D71.4080007@redhat.com> <20150930144350.GB11943@localhost.localdomain> <20150930152628.GC3989@noname.str.redhat.com> <20150930160258.GD11943@localhost.localdomain> From: Paolo Bonzini Message-ID: <560C0889.3040906@redhat.com> Date: Wed, 30 Sep 2015 18:06:33 +0200 MIME-Version: 1.0 In-Reply-To: <20150930160258.GD11943@localhost.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 3/3] block: mirror - zero unallocated target sectors when zero init not present List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody , Kevin Wolf Cc: stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org On 30/09/2015 18:02, Jeff Cody wrote: > As a general rule for blockjobs, I disagree. > > Right away, there is a key difference: we don't know that the image is > (or should be) empty. Not necessarily empty. sync='top' && mode='existing' && !target->backing_file, for example, makes sense if the target is a copy of source->bs. In fact, commit of the active layer is almost exactly a mode='existing' drive-mirror operation. But if you use mode == 'existing', and don't provide an image that follows the rules, it's garbage-in garbage-out. The sequence of operation makes sense, but the resulting image does not. Paolo > With mode != "existing", we know the image > should be empty, since we just created it (although for a host device, > it may have extraneous data in it). So I think it is not so much what > we can assume about an existing image, as it is what we cannot assume. > And that could potentially influence some block jobs.