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
