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

[Chunqiang Tang]

> 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)

FVD does have a reference count table like that in QCOW2, but it avoids 
the need for updating the reference count table during normal execution of 
the VM. The reference count table is only updated at the time of creating 
a snapshot or deleting a snapshot. Therefore, during normal execution of a 
VM, images with snapshots are as fast as images without snapshot. 

FVD can do this because of the following:

"FVD's reference count table only tracks the snapshots (s1, s2, ...), 
but does not track the "current-state". Instead,
FVD's default mechanism (one-level lookup table, journal, etc.), which 
exists
even before introducing snapshot, already tracks the "current-state". 
Working
together, FVD's reference count table and its default mechanism tracks all 
the
states. In QCOW2, when a new cluster is allocated during handling a 
running VM's
write request, it updates both the lookup table and the reference count 
table,
which is unnecessary because their information is redundant. By contrast, 
in
FVD, when a new chunk is allocated during handling a running VM's write
request, it only updates the lookup table without updating the reference 
count
table, because by design the reference count table does not track the 
"current-state" and this chunk allocation operation belongs to the 
"current-state."
This is the key why FVD can get all the functions of QCOW2's internal 
snapshot
but without its memory overhead to cache the reference count table and
its disk I/O overhead to read or write the reference count table during 
normal
execution of VM."

Regards,
ChunQiang (CQ) Tang, Ph.D.
Homepage: http://www.research.ibm.com/people/c/ctang