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: Fri, 13 Feb 2009 22:31:29 -0800 Message-ID: References: <20090211070049.GA27821@shareable.org> <49955681.9070301@suse.de> <20090213162336.GI18471@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Gleb Natapov , kvm@vger.kernel.org To: Jamie Lokier Return-path: Received: from mail-fx0-f20.google.com ([209.85.220.20]:46740 "EHLO mail-fx0-f20.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750713AbZBNGbb (ORCPT ); Sat, 14 Feb 2009 01:31:31 -0500 Received: by fxm13 with SMTP id 13so4212388fxm.13 for ; Fri, 13 Feb 2009 22:31:29 -0800 (PST) In-Reply-To: <20090213162336.GI18471@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Feb 13, 2009 at 8:23 AM, Jamie Lokier wrote: > > Marc.. this is quite a serious bug you've reported. Is there a > reason you didn't report it earlier? Because I only started hitting that bug a couple weeks ago after having upgraded to a buggy kvm version. > Is there a way to restructure the code and/or how it works so it's > more clearly correct? I am seriously concerned about the general design of qcow2. The code base is more complex than it needs to be, the format itself is susceptible to race conditions causing cluster leaks when updating some internal datastructures, it gets easily fragmented, etc. I am considering implementing a new disk image format that supports base images, snapshots (of the guest state), clones (of the disk content); that has a radically simpler design & code base; that is always consistent "on disk"; that is friendly to delta diffing (ie. space-efficient when used with ZFS snapshots or rsync); and that makes use of checksumming & replication to detect & fix corruption of critical data structures (ideally this should be implemented by the filesystem, unfortunately ZFS is not available everywhere :D). I believe the key to achieve these (seemingly utopian) goals is to represent a disk "image" as a set of sparse files, 1 per snapshot/clone. -marc