From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52413 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P5KHy-0005Py-4r for qemu-devel@nongnu.org; Mon, 11 Oct 2010 11:27:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P5KF5-00063S-5N for qemu-devel@nongnu.org; Mon, 11 Oct 2010 11:24:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P5KF4-00063F-VL for qemu-devel@nongnu.org; Mon, 11 Oct 2010 11:24:47 -0400 Message-ID: <4CB32C33.4090208@redhat.com> Date: Mon, 11 Oct 2010 17:24:35 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1286552914-27014-1-git-send-email-stefanha@linux.vnet.ibm.com> <1286552914-27014-4-git-send-email-stefanha@linux.vnet.ibm.com> <4CB18549.3020206@redhat.com> <20101011100954.GA4078@stefan-thinkpad.transitives.com> <4CB30B43.2040706@redhat.com> <20101011134241.GA5439@stefan-thinkpad.transitives.com> <4CB314C6.4040001@redhat.com> <4CB326EC.6060304@linux.vnet.ibm.com> In-Reply-To: <4CB326EC.6060304@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v2 3/7] docs: Add QED image format specification List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Anthony Liguori , Christoph Hellwig , Stefan Hajnoczi , qemu-devel@nongnu.org On 10/11/2010 05:02 PM, Anthony Liguori wrote: > On 10/11/2010 08:44 AM, Avi Kivity wrote: >> On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote: >>> > >>> > A leak is acceptable (it won't grow; it's just an unused, incorrect >>> > freelist), but data corruption is not. >>> >>> The alternative is for the freelist to be a non-compat feature bit. >>> That means older QEMU binaries cannot use a QED image that has enabled >>> the freelist. >> >> For this one feature. What about others? > > A compat feature is one where the feature can be completely ignored > (meaning that the QEMU does not have to understand the data format). > > An example of a compat feature is copy-on-read. It's merely a > suggestion and there is no additional metadata. If a QEMU doesn't > understand it, it doesn't affect it's ability to read the image. > > An example of a non-compat feature would be zero cluster entries. > Zero cluster entries are a special L2 table entry that indicates that > a cluster's on-disk data is all zeros. As long as there is at least 1 > ZCE in the L2 tables, this feature bit must be set. As soon as all of > the ZCE bits are cleared, the feature bit can be unset. > > An older QEMU will gracefully fail when presented with an image using > ZCE bits. An image with no ZCEs will work on older QEMUs. > What's the motivation behind ZCE? There is yet a third type of feature, one which is not strictly needed in order to use the image, but if used, must be kept synchronized. An example is the freelist. Another example is a directory index for a filesystem. I can't think of another example which would be relevant to QED -- metadata checksums perhaps? -- we can always declare it a non-compatible feature, but of course, it reduces compatibility. -- error compiling committee.c: too many arguments to function