From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34516 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou2NO-0005H2-Fv for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:06:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou2NM-0008Jz-Mp for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:06:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9448) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou2NM-0008Jk-Dp for qemu-devel@nongnu.org; Fri, 10 Sep 2010 08:06:40 -0400 Message-ID: <4C8A1F46.1090308@redhat.com> Date: Fri, 10 Sep 2010 15:06:30 +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> 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 02:43 PM, Stefan Hajnoczi wrote: >> >>> and/or enterprise storage. >> That doesn't eliminate undiscovered errors (they can still come from the >> transport). > Eliminating silent data corruption is currently not a goal for any > disk image format I know of. For filesystems, I know that ZFS and > btrfs will try to detect corruption using data checksumming. > > The guest filesystem, the disk image format, or the host filesystem > could do checksumming. The hypervisor should keep out of the way in > the interest of performance and emulation fidelity. Why does > checksumming need to be done in the image format? Isn't the choice > between host and guest filesystem checksumming already enough? You're correct about the data. It's better to do it at the end-point in any case. The metadata is something else - an error in a cluster table is magnified so it is likely to cause the loss of an entire image, and there's nothing the guest can do about it. btrfs duplicates metadata to avoid this (but if we have btrfs underneath, we can just use raw). >> qcow2 exists, people use it, and by the time qed is offered on distros (even >> more on enterprise distros), there will be a lot more qcow2 images. Not >> everyone runs qemu.git HEAD. >> >> What will you tell those people? Upgrade your image? They may still want >> to share it with older installations. What if they use features not present >> in qed? Bad luck? >> >> qcow2 is going to live forever no matter what we do. > It should be possible to do (live) upgrades for supported images. > That only solves part of the problem. Please TRIM below the last line of your message. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.