From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=35221 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou3eU-00070C-9N for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:28:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou3eT-000400-9w for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:28:26 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:62653) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou3eT-0003zn-73 for qemu-devel@nongnu.org; Fri, 10 Sep 2010 09:28:25 -0400 Received: by iwn38 with SMTP id 38so2281746iwn.4 for ; Fri, 10 Sep 2010 06:28:24 -0700 (PDT) Message-ID: <4C8A3273.30707@codemonkey.ws> Date: Fri, 10 Sep 2010 08:28:19 -0500 From: Anthony Liguori 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> <4C8A1F46.1090308@redhat.com> In-Reply-To: <4C8A1F46.1090308@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: Avi Kivity Cc: Kevin Wolf , Stefan Hajnoczi , Stefan Hajnoczi , qemu-devel@nongnu.org On 09/10/2010 07:06 AM, Avi Kivity wrote: > 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). What it really comes down to is that checksumming is a filesystem feature that requires a sophisticated way of handling metadata which puts it beyond the scope of what an image format should be. The point of an image format is to make it a filesystem from 10 years ago in terms of sophistication and leave the cutting edge file system research to file system developers. Regards, Anthony Liguori