[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Mon, 14 Mar 2011 18:57:59 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]