From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37620)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1ZuH7P-0007VM-Ts
	for qemu-devel@nongnu.org; Thu, 05 Nov 2015 04:46:08 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1ZuH7M-0002gC-NO
	for qemu-devel@nongnu.org; Thu, 05 Nov 2015 04:46:07 -0500
Received: from mx1.redhat.com ([209.132.183.28]:43162)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <famz@redhat.com>) id 1ZuH7M-0002g7-J3
	for qemu-devel@nongnu.org; Thu, 05 Nov 2015 04:46:04 -0500
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (Postfix) with ESMTPS id 469258E236
	for <qemu-devel@nongnu.org>; Thu,  5 Nov 2015 09:46:04 +0000 (UTC)
Date: Thu, 5 Nov 2015 17:46:01 +0800
From: Fam Zheng <famz@redhat.com>
Message-ID: <20151105094601.GA14058@ad.usersys.redhat.com>
References: <20151104163730.GB28428@redhat.com>
	<20151105071449.GH24893@ad.usersys.redhat.com>
	<20151105085622.GQ29330@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151105085622.GQ29330@redhat.com>
Subject: Re: [Qemu-devel] Should 'qemu-img commit' sparsify the backing file?
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: qemu-devel@nongnu.org

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 I think we can implement a dedicate "sparsify" command to do that, though.

> 
> > > (3) Sparsify the overlay:
> > > 
> > > $ virt-sparsify --in-place overlay.qcow2 
> > > $ du -sh fedora-22.img overlay.qcow2 
> > > 6.1G fedora-22.img
> > > 3.2M overlay.qcow2
> >     qemu-img convert fedora-22.img fedora-22.img.1
> > 
> > I don't think we have an in-place sparsifier now.
> 
> virt-sparsify ...
> 

Does virt-sparsify work if there is no file system present (e.g. the disk is
fully filled with zeroes) on the device?

Fam