From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=60497 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OtoAT-00023F-40
	for qemu-devel@nongnu.org; Thu, 09 Sep 2010 16:56:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <hch@lst.de>) id 1OtoAR-0005uO-Sf
	for qemu-devel@nongnu.org; Thu, 09 Sep 2010 16:56:24 -0400
Received: from verein.lst.de ([213.95.11.210]:46774)
	by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <hch@lst.de>)
	id 1OtoAR-0005u5-IX
	for qemu-devel@nongnu.org; Thu, 09 Sep 2010 16:56:23 -0400
Date: Thu, 9 Sep 2010 22:56:15 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] Re: [RFC] qed: Add QEMU Enhanced Disk format
Message-ID: <20100909205615.GA30223@lst.de>
References: <4C865CFE.7010508@codemonkey.ws> <4C8663C4.1090508@redhat.com>
	<4C866773.2030103@codemonkey.ws>
	<4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com>
	<4C87860A.3060904@codemonkey.ws> <4C888287.8020209@redhat.com>
	<4C88D7CC.5000806@codemonkey.ws> <4C890FD1.6060105@redhat.com>
	<4C891322.9020104@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C891322.9020104@codemonkey.ws>
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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Avi Kivity <avi@redhat.com>

On Thu, Sep 09, 2010 at 12:02:26PM -0500, Anthony Liguori wrote:
> My position is that we'll need a sparse image format well into the 
> future because while btrfs may be ubiquitous as a file system, IRL, 
> people transfer images around all of the time through dumb transports 
> like HTTP and fat-formatted USB keys.  A 100GB image with 1GB allocated 
> cannot explode to 100GB just because HTTP is a dump transport.
> 
> Where we should do copy-on-read is a different topic.  Really, I should 
> have waited to share that feature to avoid confusing the current discussion.

Yes, we will need an image format forever.  However I'd be a much
happier camper if typical production setups wouldn't use them.

Either way the qed image format is something that too me looks much
better than qcow2, primarily due to the simpliciy.  I haven't managed
to fully review it yet, so I might change my opinion again.