From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KoaSA-0003s6-HT
	for qemu-devel@nongnu.org; Sat, 11 Oct 2008 05:08:02 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KoaS8-0003qy-7Q
	for qemu-devel@nongnu.org; Sat, 11 Oct 2008 05:08:01 -0400
Received: from [199.232.76.173] (port=52886 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KoaS7-0003qj-Rb
	for qemu-devel@nongnu.org; Sat, 11 Oct 2008 05:07:59 -0400
Received: from rv-out-0708.google.com ([209.85.198.248]:3410)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <balrogg@gmail.com>) id 1KoaS5-0006sg-UZ
	for qemu-devel@nongnu.org; Sat, 11 Oct 2008 05:07:58 -0400
Received: by rv-out-0708.google.com with SMTP id f25so801212rvb.22
	for <qemu-devel@nongnu.org>; Sat, 11 Oct 2008 02:07:56 -0700 (PDT)
Message-ID: <fb249edb0810110207q481d897cq5cbbb56f6ddf0af1@mail.gmail.com>
Date: Sat, 11 Oct 2008 11:07:56 +0200
From: "andrzej zaborowski" <balrogg@gmail.com>
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
In-Reply-To: <48EF4BD7.3040000@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <48EE38B9.2050106@codemonkey.ws> <48EF1D55.7060307@redhat.com>
	<48EF4BD7.3040000@codemonkey.ws>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, Ryan Harper <ryanh@us.ibm.com>, Laurent Vivier <Laurent.Vivier@bull.net>, kvm-devel <kvm-devel@lists.sourceforge.net>

2008/10/10 Anthony Liguori <anthony@codemonkey.ws>:
> I think qcow2 will be okay because the only issue is image expansion and
> that is a relatively uncommon case that is amortized throughout the life
> time of the VM.

It's discutible how common this is and if you can count on the
amortization.  I'd say that for most users creating new short-lived
VMs is the bigger slice of their time using qemu.  Fore example think
about the trying out different distros like with free.oszoo.org, most
images there are qcow2.  Similarly trying to install an os and booting
its kernel with different options in sequence, is where waiting is
most annoying.  Also -snapshot uses qcow2.

In any case let's have benchmarks before deciding anything about
chagning the default behavior.  Since about 0.9.0 qemu is going
through a lot of (necessary) changes that in a great part were slow
downs, and they really accumulated.

Regards