From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lnnp1-0006n0-DT for qemu-devel@nongnu.org; Sun, 29 Mar 2009 01:44:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lnnow-0006mh-Or for qemu-devel@nongnu.org; Sun, 29 Mar 2009 01:44:39 -0400 Received: from [199.232.76.173] (port=34512 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lnnow-0006me-Ga for qemu-devel@nongnu.org; Sun, 29 Mar 2009 01:44:34 -0400 Received: from mx2.redhat.com ([66.187.237.31]:35200) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lnnow-00080h-3K for qemu-devel@nongnu.org; Sun, 29 Mar 2009 01:44:34 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n2T5iXZB030721 for ; Sun, 29 Mar 2009 01:44:33 -0400 Message-ID: <49CF0AE7.4010500@redhat.com> Date: Sun, 29 Mar 2009 08:45:11 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [6907] Introducing qcow2 extensions (Uri Lublin) References: <49CE7352.1050800@redhat.com> <49CECB28.30306@codemonkey.ws> In-Reply-To: <49CECB28.30306@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: uri Lublin Anthony Liguori wrote: >> We should introduce a notion of compatible vs. incompatible extensions. >> >> A compatible extension my be ignored by the qcow2 code if it does not >> understand the magic number. An incompatible extension causes an >> abort. This allows both more flexibility in how we can change the >> file format. I believe ext* does the same thing. > > I was assuming that all extensions would be compatible. I don't like > the idea of having qcow2 files floating around that require specific > version of QEMU. > > For that, we should just bump to qcow3 (that's what versioning is for, > right? :-). The problem is that you would need to bump the version each time you made an incompatible change. We'd end up with qcow4351 very quickly. One option is to declare qcow3 as qcow2 + all incompatible extensions just before 0.11. Another is to require explicit user action to enable an incompatible option. If you did that, you could expect only to upgrade qemu, not degrade, but that's a reasonable assumption in many scenarios. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.