From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=37559 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OoGoT-0005WP-FK
	for qemu-devel@nongnu.org; Wed, 25 Aug 2010 10:18:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <hch@lst.de>) id 1OoGoO-00080i-Ne
	for qemu-devel@nongnu.org; Wed, 25 Aug 2010 10:18:49 -0400
Received: from verein.lst.de ([213.95.11.210]:55934)
	by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <hch@lst.de>)
	id 1OoGoO-0007ve-Eb
	for qemu-devel@nongnu.org; Wed, 25 Aug 2010 10:18:44 -0400
Date: Wed, 25 Aug 2010 16:18:30 +0200
From: Christoph Hellwig <hch@lst.de>
Message-ID: <20100825141830.GA31307@lst.de>
References: <4C73C926.3010901@codemonkey.ws> <4C73C9CF.7090800@redhat.com>
	<4C73CAA9.2060104@codemonkey.ws> <4C73CB85.9010306@redhat.com>
	<4C73CBD6.7000900@codemonkey.ws> <4C73CCCB.6050704@redhat.com>
	<4C73CF8D.5060405@codemonkey.ws> <4C74C2F3.9050506@redhat.com>
	<4C7510C1.8080305@codemonkey.ws> <4C75195A.8050508@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C75195A.8050508@redhat.com>
Subject: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use
	bdrv_(p)write_sync for metadata writes"
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, stefanha@gmail.com, mjt@tls.msk.ru, qemu-devel@nongnu.org, hch@lst.de

On Wed, Aug 25, 2010 at 04:23:38PM +0300, Avi Kivity wrote:
>  On 08/25/2010 03:46 PM, Anthony Liguori wrote:
> >
> >If we had another disk format that only supported growth and metadata 
> >for a backing file, can you think of another failure scenario?
> 
> btw, only supporting growth is a step backwards.  Currently file-backed 
> disks keep growing even the guest-used storage doesn't grow, since once 
> we allocate something we never release it.  But eventually guests will 
> start using TRIM or DISCARD or however it's called, and then we can 
> expose it and reclaim unused blocks.

Together with file level snapshots Thin Provisioning support basically
makes qcow2 obsolete.

I already have a prototype implementation of scsi discard for qemu,
which together with the XFS extent size hints allows us to very
efficiently using growing and shrinking images on the bare filesystem.
XFS at this point doesn't have file-level snapshots, but I'm planning
to port the hole punhing and extent size hints to btrfs and maybe
ocfs2 which will give you all that.