[Top][All Lists]

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

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

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Mon, 14 Mar 2011 15:05:38 +0000

On Mon, Mar 14, 2011 at 2:49 PM, Anthony Liguori <address@hidden> wrote:
> 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
>>>>             |->(curren-state)
>>>> 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.

Here is a problem: there is a single global refcount table in QCOW2.
You need to synchronize updates of the refcounts between multiple
writers to avoid introducing incorrect refcounts.


reply via email to

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