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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, Mar 14, 2011 at 2:49 PM, Anthony Liguori <anthony@codemonkey.ws> 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.

Stefan