From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57207 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PqXHc-0001sW-Aw for qemu-devel@nongnu.org; Fri, 18 Feb 2011 15:50:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PqXHa-0004B2-KE for qemu-devel@nongnu.org; Fri, 18 Feb 2011 15:50:31 -0500 Received: from mail-vx0-f173.google.com ([209.85.220.173]:36068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PqXHa-0004Aw-Ga for qemu-devel@nongnu.org; Fri, 18 Feb 2011 15:50:30 -0500 Received: by vxb40 with SMTP id 40so2311852vxb.4 for ; Fri, 18 Feb 2011 12:50:29 -0800 (PST) Message-ID: <4D5EDB93.1070802@codemonkey.ws> Date: Fri, 18 Feb 2011 14:50:27 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Strategic decision: COW format References: <4D5BC467.4070804@redhat.com> <4D5E4271.80501@redhat.com> <4D5EAFA8.70909@mail.berlios.de> <4D5EC457.506@redhat.com> <4D5ECCE7.2060607@codemonkey.ws> <4D5EDB61.2090509@redhat.com> In-Reply-To: <4D5EDB61.2090509@redhat.com> 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: Kevin Wolf Cc: Chunqiang Tang , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi On 02/18/2011 02:49 PM, Kevin Wolf wrote: > Am 18.02.2011 20:47, schrieb Anthony Liguori: > >> On 02/18/2011 01:11 PM, Kevin Wolf wrote: >> >>>> A new file format like fvd would be a challenge for the existing ones. >>>> Declare its support as unsupported or experimental, but let users >>>> decide which one is best suited to their needs! >>>> >>>> >>> Basically this is what we did for QED. In hindsight I consider it a >>> mistake because it set a bad precedence of inventing something new >>> instead of fixing what's there. >>> >> I don't see how qcow3 is fixing something that's there since it's still >> an incompatible format. >> >> It'd be a stronger argument if you were suggesting something that was >> still fully compatible with qcow2 but once compatibility is broken, it's >> broken. >> > It's really more like adding an incompatible feature flag in QED. You > still have one implementation for old and new images instead of > splitting up development efforts, you still have all of the features and > so on. In theory. Since an implementation doesn't exist, we have no idea how much code is actually going to be shared at the end of the day. I suspect that, especially if you drop the ref table updates, there won't be an awful lot of common code in the two paths. Regards, Anthony Liguori > It's a completely different story than QED. > > Kevin >