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

[Kevin Wolf <kwolf@redhat.com>]

Am 14.03.2011 17:32, schrieb Chunqiang Tang:
>>> FVD's novel uses of the reference count table reduces the metadata 
> update
>>> overhead down to literally zero during normal execution of a VM. This 
> gets
>>> the bests of QCOW2's reference count table but without its oeverhead. 
> In
>>> FVD, the reference count table is only updated when creating a new
>>> snapshot or deleting an existing snapshot. The reference count table 
> is
>>> never updated during normal execution of a VM.
>>
>> Do you want to send out a break-down of the steps (and cost) involved in 
> doing:
>>
>> 1. Snapshot creation.
>> 2. Snapshot deletion.
>> 3. Opening an image with n snapshots.
> 
> Here is a detailed description. Relevant to the discussion of snapshot, 
> FVD uses a one-level lookup table and a refcount table. FVD’s one-level 
> lookup table is very similar to QCOW2’s two-level lookup table, except 
> that it is much smaller in FVD, and is preallocated and hence contiguous 
> in image.

Does this mean that FVD can't hold VM state of arbitrary size?

> FVD’s refcount table is almost identical to that of QCOW2, but with a key 
> difference. An image consists of an arbitrary number of read-only 
> snapshots, and a single writeable image front, which is the current image 
> state perceived by the VM. Below, I will simply refer to the read-only 
> snapshots as snapshots, and refer to the “writeable image front” as 
> “writeable-front.” QCOW2’s refcount table counts clusters that are used by 
> either read-only snapshots or writeable-front. Because writeable-front 
> changes as the VM runs, QCOW2 needs to update the refcount table on the 
> fast path of normal VM execution. 

Needs to update, but not necessarily on the fast path. Updates can be
delayed and batched.

Kevin