From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38907 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou30i-0003wo-HF for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:47:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou30h-0006DD-CV for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:47:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38913) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou30h-0006D8-5h for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:47:19 -0400 Message-ID: <4C8A28C5.9010704@redhat.com> Date: Fri, 10 Sep 2010 15:47:01 +0300 From: Avi Kivity 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; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org On 09/10/2010 03:35 PM, Stefan Hajnoczi wrote: > >> 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. > > 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. I > think the reason we haven't seen them before is because the effort and > the baggage of doing them is too great. Sure, we maintain existing > formats but I don't see active development pushing virtualized storage > happening. The same could be said about much of qemu. It is an old code base that wasn't designed for virtualization. Yet we maintain it and develop it because compatibility is king. (as an aside, qcow2 is better positioned for TRIM support than qed is) > Do you think qcow2 is the right format for the future? The flagship > disk image format for KVM? If we were starting from scratch, no. But we aren't starting from scratch. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.