From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37213 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou3xl-0006DV-5P for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:48:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou3xh-00075s-2h for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:48:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23271) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou3xg-00075m-Sh for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:48:17 -0400 Message-ID: <4C8A372E.7060407@redhat.com> Date: Fri, 10 Sep 2010 15:48:30 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C84E738.3020802@codemonkey.ws> <4C865187.6090508@redhat.com> <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> <4C8A1311.8070903@redhat.com> <4C8A20B8.1040800@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi Am 10.09.2010 14:35, schrieb Stefan Hajnoczi: > On Fri, Sep 10, 2010 at 1:12 PM, Kevin Wolf wrote: >> Am 10.09.2010 13:43, schrieb Stefan Hajnoczi: >>>>>>> By creating two code paths within qcow2. >>>>>> >>>>>> You're creating two code paths for users. >>>>> >>>>> No, I'm creating a single path: QED. >>>>> >>>>> There are already two code paths: raw and qcow2. qcow2 has had such a bad >>>>> history that for a lot of users, it's not even a choice. >>>> >>>> qcow2 exists, people use it, and by the time qed is offered on distros (even >>>> more on enterprise distros), there will be a lot more qcow2 images. Not >>>> everyone runs qemu.git HEAD. >>>> >>>> What will you tell those people? Upgrade your image? They may still want >>>> to share it with older installations. What if they use features not present >>>> in qed? Bad luck? >>>> >>>> qcow2 is going to live forever no matter what we do. >>> >>> It should be possible to do (live) upgrades for supported images. >> >> That still leaves those qcow2 images that use features not supported by >> qed. Just a few features missing in qed are internal snapshots, qcow2 on >> block devices, compression, encryption. So qed can't be a complete >> replacement for qcow2 (and that was the whole point of doing qed). If >> anything, it can exist besides qcow2. > > qcow2 is a feature-driven format. It sacrifices some of the core > qualities of an image format in exchange for advanced features. I > like to use qcow2 myself for desktop virtualization. > > qed applies the 80/20 rule to disk image formats. Let's perfect the > basics for most users at a fraction of the {development,performance} > cost. So let's translate this into an answer to the question we're discussing here: Yes, Avi is right, qcow2 is going to live forever. > Then, with a clean base that takes on board the lessons of existing > formats it is much easier to innovate. Look at the image streaming, > defragmentation, and trim ideas that are playing out right now. All of these are possible with qcow2 as well or even better than with qed. For example trim feels like a really hacky thing in qed whereas freeing a cluster is something just natural in qcow2. Kevin