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

[Kevin Wolf <kwolf@redhat.com>]

Am 14.03.2011 15:49, schrieb Anthony Liguori:
> 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.

You would run into problems with the COW flag in the L2 tables. They are
only an optimization, though, so you could probably avoid using them and
directly look up the refcount table for each write, at the cost of
performance.

Anyway, I don't think there's a real use case for something like this.

Kevin