From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53204 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou66u-0006aO-Rl for qemu-devel@nongnu.org; Fri, 10 Sep 2010 12:06:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou66h-000868-VN for qemu-devel@nongnu.org; Fri, 10 Sep 2010 12:05:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6603) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou66h-000862-Nn for qemu-devel@nongnu.org; Fri, 10 Sep 2010 12:05:43 -0400 Message-ID: <4C8A575E.7080505@redhat.com> Date: Fri, 10 Sep 2010 18:05:50 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com> <4C87860A.3060904@codemonkey.ws> <4C888287.8020209@redhat.com> <4C88D7CC.5000806@codemonkey.ws> <4C8A1311.8070903@redhat.com> <4C8A15C4.40201@redhat.com> <4C8A19CA.3040000@redhat.com> <4C8A3106.8050501@codemonkey.ws> <20100910134859.GB28831@lst.de> <4C8A488B.2090907@codemonkey.ws> <4C8A4C61.2030905@redhat.com> <4C8A5488.9000409@codemonkey.ws> In-Reply-To: <4C8A5488.9000409@codemonkey.ws> 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: Anthony Liguori Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , Christoph Hellwig , Stefan Hajnoczi , Avi Kivity Am 10.09.2010 17:53, schrieb Anthony Liguori: > On 09/10/2010 10:18 AM, Kevin Wolf wrote: >> Am 10.09.2010 17:02, schrieb Anthony Liguori: >> >>> What makes us future proof is having a good feature support. qcow2 >>> doesn't have this. We have a good way at making purely informational >>> changes and also making changes that break the format. Those features >>> are independent so they can be backported in a compatible way too. >>> >> I might have agreed that it's useful to be able to backport them >> independently if we had had lots of such features added in the past. But >> we haven't. >> > > I think part of why we haven't had them is that the mechanisms aren't > very flexible. > > A good example of where feature support would be very nice is for > changing the way snapshots metadata is recorded in qcow2. > > It would be nice to be able to represent snapshots with a uuid. If you > added new metadata that had uuid based snapshots that were hierarchical > and added a feature bit, it would have some nice properties. > > Since most images don't have snapshots, the common case would be a qcow2 > that was fully backwards compatible. You would also get a graceful > failure for using a new image with an old QEMU. Well, snapshots have an ID today (which is different from their name). Nobody stops you from putting a UUID there. Fully backwards compatible, no feature flag needed. I think Miguel was planning to actually do this. Kevin