All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Bevand <m.bevand@gmail.com>
To: dlaor@redhat.com
Cc: Jamie Lokier <jamie@shareable.org>,
	qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Re: qcow2 corruption observed, fixed by reverting old change
Date: Sat, 14 Feb 2009 23:56:58 -0800	[thread overview]
Message-ID: <aaccfcb60902142356o3249a906q4696ae608517a75e@mail.gmail.com> (raw)
In-Reply-To: <499745A1.3040707@redhat.com>

On Sat, Feb 14, 2009 at 2:28 PM, Dor Laor <dlaor@redhat.com> 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

WARNING: multiple messages have this Message-ID (diff)
From: Marc Bevand <m.bevand@gmail.com>
To: dlaor@redhat.com
Cc: qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Re: qcow2 corruption observed, fixed by reverting old change
Date: Sat, 14 Feb 2009 23:56:58 -0800	[thread overview]
Message-ID: <aaccfcb60902142356o3249a906q4696ae608517a75e@mail.gmail.com> (raw)
In-Reply-To: <499745A1.3040707@redhat.com>

On Sat, Feb 14, 2009 at 2:28 PM, Dor Laor <dlaor@redhat.com> 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

  parent reply	other threads:[~2009-02-15  7:57 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-11  7:00 qcow2 corruption observed, fixed by reverting old change Jamie Lokier
2009-02-11  7:00 ` [Qemu-devel] " Jamie Lokier
2009-02-11  9:57 ` Kevin Wolf
2009-02-11 11:27   ` Jamie Lokier
2009-02-11 11:27     ` Jamie Lokier
2009-02-11 11:41   ` Jamie Lokier
2009-02-11 11:41     ` Jamie Lokier
2009-02-11 12:41     ` Kevin Wolf
2009-02-11 12:41       ` Kevin Wolf
2009-02-11 16:48       ` Jamie Lokier
2009-02-11 16:48         ` Jamie Lokier
2009-02-12 22:57         ` Consul
2009-02-12 22:57           ` [Qemu-devel] " Consul
2009-02-12 23:19           ` Consul
2009-02-12 23:19             ` [Qemu-devel] " Consul
2009-02-13  7:50             ` Marc Bevand
2009-02-16 12:44         ` [Qemu-devel] " Kevin Wolf
2009-02-17  0:43           ` Jamie Lokier
2009-02-17  0:43             ` Jamie Lokier
2009-03-06 22:37         ` Filip Navara
2009-03-06 22:37           ` Filip Navara
2009-02-12  5:45       ` Chris Wright
2009-02-12  5:45         ` Chris Wright
2009-02-12 11:08         ` Johannes Schindelin
2009-02-12 11:08           ` Johannes Schindelin
2009-02-13  6:41 ` Marc Bevand
2009-02-13 11:16   ` Kevin Wolf
2009-02-13 11:16     ` [Qemu-devel] " Kevin Wolf
2009-02-13 16:23     ` Jamie Lokier
2009-02-13 16:23       ` Jamie Lokier
2009-02-13 18:43       ` Chris Wright
2009-02-13 18:43         ` Chris Wright
2009-02-14  6:31       ` Marc Bevand
2009-02-14 22:28         ` Dor Laor
2009-02-14 22:28           ` Dor Laor
2009-02-15  2:27           ` Jamie Lokier
2009-02-15  7:56           ` Marc Bevand [this message]
2009-02-15  7:56             ` Marc Bevand
2009-02-15  2:37         ` Jamie Lokier
2009-02-15 10:57     ` Gleb Natapov
2009-02-15 10:57       ` [Qemu-devel] " Gleb Natapov
2009-02-15 11:46       ` Marc Bevand
2009-02-15 11:46         ` [Qemu-devel] " Marc Bevand
2009-02-15 11:54         ` Marc Bevand
2009-02-15 11:54           ` [Qemu-devel] " Marc Bevand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aaccfcb60902142356o3249a906q4696ae608517a75e@mail.gmail.com \
    --to=m.bevand@gmail.com \
    --cc=dlaor@redhat.com \
    --cc=gleb@redhat.com \
    --cc=jamie@shareable.org \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.