From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Bevand Subject: Re: [Qemu-devel] Re: qcow2 corruption observed, fixed by reverting old change Date: Sat, 14 Feb 2009 23:56:58 -0800 Message-ID: References: <20090211070049.GA27821@shareable.org> <49955681.9070301@suse.de> <20090213162336.GI18471@shareable.org> <499745A1.3040707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , qemu-devel@nongnu.org, Gleb Natapov , kvm@vger.kernel.org To: dlaor@redhat.com Return-path: Received: from mail-bw0-f161.google.com ([209.85.218.161]:49347 "EHLO mail-bw0-f161.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750718AbZBOH5A (ORCPT ); Sun, 15 Feb 2009 02:57:00 -0500 Received: by bwz5 with SMTP id 5so2510029bwz.13 for ; Sat, 14 Feb 2009 23:56:58 -0800 (PST) In-Reply-To: <499745A1.3040707@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sat, Feb 14, 2009 at 2:28 PM, Dor Laor wrote: > > Both qcow2 and vmdk have the ability to keep 'external' snapshots. I know but they don't implement one feature I cited: clones, or "writable snapshots", which I would like implemented with support for deduplication. Base images / backing files are too limited because they have to be managed by the enduser and there is no deduplication done between multiple images based on the same backing file. > We might use vmdk format or VHD as a base for the future high performing, > safe image format for qemu Neither vmdk nor vhd satisfy my requirements: not always consistent on disk, no possibility of detecting/correcting errors, susceptible to fragmentation (affects vmdk, not sure about vhd), and possibly others. Jamie: yes in an ideal world, the storage virtualization layer could make use of the host's filesystem or block layer snapshotting/cloning features, but in the real world too few OSes implement these. -marc From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LYbsA-0004ZP-1e for qemu-devel@nongnu.org; Sun, 15 Feb 2009 02:57:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LYbs7-0004Ye-Rs for qemu-devel@nongnu.org; Sun, 15 Feb 2009 02:57:04 -0500 Received: from [199.232.76.173] (port=46847 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYbs7-0004YZ-HP for qemu-devel@nongnu.org; Sun, 15 Feb 2009 02:57:03 -0500 Received: from mx20.gnu.org ([199.232.41.8]:8498) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LYbs6-0001HR-W8 for qemu-devel@nongnu.org; Sun, 15 Feb 2009 02:57:03 -0500 Received: from mail-fx0-f20.google.com ([209.85.220.20]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LYbs5-000772-3q for qemu-devel@nongnu.org; Sun, 15 Feb 2009 02:57:01 -0500 Received: by fxm13 with SMTP id 13so4971796fxm.10 for ; Sat, 14 Feb 2009 23:56:58 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <499745A1.3040707@redhat.com> References: <20090211070049.GA27821@shareable.org> <49955681.9070301@suse.de> <20090213162336.GI18471@shareable.org> <499745A1.3040707@redhat.com> Date: Sat, 14 Feb 2009 23:56:58 -0800 Message-ID: Subject: Re: [Qemu-devel] Re: qcow2 corruption observed, fixed by reverting old change From: Marc Bevand Content-Type: text/plain; charset=ISO-8859-1 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: dlaor@redhat.com Cc: qemu-devel@nongnu.org, Gleb Natapov , kvm@vger.kernel.org On Sat, Feb 14, 2009 at 2:28 PM, Dor Laor wrote: > > Both qcow2 and vmdk have the ability to keep 'external' snapshots. I know but they don't implement one feature I cited: clones, or "writable snapshots", which I would like implemented with support for deduplication. Base images / backing files are too limited because they have to be managed by the enduser and there is no deduplication done between multiple images based on the same backing file. > We might use vmdk format or VHD as a base for the future high performing, > safe image format for qemu Neither vmdk nor vhd satisfy my requirements: not always consistent on disk, no possibility of detecting/correcting errors, susceptible to fragmentation (affects vmdk, not sure about vhd), and possibly others. Jamie: yes in an ideal world, the storage virtualization layer could make use of the host's filesystem or block layer snapshotting/cloning features, but in the real world too few OSes implement these. -marc