[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: qcow2 corruption observed, fixed by reverting old c

From: Dor Laor
Subject: Re: [Qemu-devel] Re: qcow2 corruption observed, fixed by reverting old change
Date: Sun, 15 Feb 2009 00:28:49 +0200
User-agent: Thunderbird (X11/20081119)

Marc Bevand wrote:
On Fri, Feb 13, 2009 at 8:23 AM, Jamie Lokier <address@hidden> 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
Both qcow2 and vmdk have the ability to keep 'external' snapshots.
In addition to what you wrote, qcow2 is missing journal for its meta data and
also performs poorly because of complex meta data and sync calls.

We might use vmdk format or VHD as a base for the future high performing, safe
image format for qemu
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to address@hidden
More majordomo info at  http://vger.kernel.org/majordomo-info.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]