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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Regards,

Anthony Liguori

> Kevin
>