[Top][All Lists]

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

Re: [Qemu-devel] Re: Strategic decision: COW format

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Mon, 14 Mar 2011 09:49:45 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/14/2011 09:21 AM, Kevin Wolf wrote:
Am 14.03.2011 15:02, schrieb Anthony Liguori:
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving between snapshots.

The equivalent for external snapshots would be:

base0<- base1<- base2<- image

And then if I wanted to move to base1 without destroying base2 and
image, I could do:

qemu-img create -f qcow2 -b base1 base1-overlay.img

The file system can keep a lot of these things around pretty easily but
with your proposal, it seems like there can only be one.  If you support
many of them, I think you'll degenerate to something as complex as a
reference count table.

On the other hand, I think it's reasonable to just avoid the CoW overlay
entirely and say that moving to a previous snapshot destroys any of it's
children.  I think this ends up being a simplifying assumption that is
worth investigating further.
No, both VMware and FVD have the same semantics as QCOW2. Moving to a
previous snapshot does not destroy any of its children. In the example I
gave (copied below),
it goes from

Image: s1->s2->s3->s4->(current-state)

back to snapshot s2, and now the state is

Image: s1->s2->s3->s4

where all snapshots s1-s4 are kept. From there, it can take another
snapshot s5, and then further go back to snapshot s4, ending up with

Image: s1->s2->s3->s4
             |->s5   |
                     |->   (current-state)
Your use of "current-state" is confusing me because AFAICT,
current-state is just semantically another snapshot.

It's writable because it has no children.  You only keep around one
writable snapshot and to make another snapshot writable, you have to
discard the former.

This is not the semantics of qcow2.  Every time you create a snapshot,
it's essentially a new image.  You can write directly to it.

While we don't do this today and I don't think we ever should, it's
entirely possible to have two disks served simultaneously out of the
same qcow2 file using snapshots.
No, CQ is describing the semantics of internal snapshots in qcow2
correctly. You have all the snapshots that are stored in the snapshot
table (all read-only) plus one current state described by the image
header (read-write).

But is there any problem (in the format) with writing to the non-current state? I can't think of one.


Anthony Liguori


reply via email to

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