From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvovG-000313-GT for qemu-devel@nongnu.org; Mon, 09 Nov 2015 11:04:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvovB-0006Gp-Ds for qemu-devel@nongnu.org; Mon, 09 Nov 2015 11:03:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvovB-0006FN-9f for qemu-devel@nongnu.org; Mon, 09 Nov 2015 11:03:53 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 7D488F8054 for ; Mon, 9 Nov 2015 16:03:52 +0000 (UTC) Date: Mon, 9 Nov 2015 17:03:50 +0100 From: Kevin Wolf Message-ID: <20151109160350.GA3621@noname.redhat.com> References: <20151104163730.GB28428@redhat.com> <20151105071449.GH24893@ad.usersys.redhat.com> <20151105085622.GQ29330@redhat.com> <20151105094601.GA14058@ad.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151105094601.GA14058@ad.usersys.redhat.com> Subject: Re: [Qemu-devel] Should 'qemu-img commit' sparsify the backing file? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: "Richard W.M. Jones" , qemu-devel@nongnu.org Am 05.11.2015 um 10:46 hat Fam Zheng geschrieben: > On Thu, 11/05 08:56, Richard W.M. Jones wrote: > > On Thu, Nov 05, 2015 at 03:14:49PM +0800, Fam Zheng wrote: > > > I don't think this the purpose of "qemu-img commit". Committing > > > "new" data in overlay.qcow2 has little to do with discarding backing > > > image's fragments where there are only explict zeroes. > > > > In that case, why didn't this step sparsify the backing file? > > Commit should be (by default, at least) as fast as possible, so committing > overlay.qcow2 shouldn't involve scanning the whole backing file. But if we do need to commit some data to the backing file, we should try to be efficient (i.e. use zero clusters in the backing file). I think your mirror fixes achieve this. This should actually be enough for virt-sparsify because IIUC it fills the overlay with zero clusters in the right places before committing. Kevin