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

[Chunqiang Tang]

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

No, FVD can hold VM state of an arbitrary size. Unlike QCOW2, FVD does not 
store the index of the vm state as part of the one-level lookup table. FVD 
could have done so, and then relocates the one-level lookup table in order 
grow it in size (growing FVD's lookup table through relocation is 
supported, e.g., in order to resize an image to a larger size), but that's 
not an ideal solution. Instead, in FVD, each snapshot has two fields, 
vm_state_offset and vm_state_space_size, which directly point to where the 
VM state is stored, and vm_state_space_size can be arbitrary. BTW, I 
observe "uint32_t QEMUSnapshotInfo.vm_state_size". Does this mean that a 
VM state cannot be larger than 4GB? This seems to be a limitation of QEMU. 
FVD instead uses "uint64_t vm_state_space_size" in the image format, in 
case that the size of QEMUSnapshotInfo.vm_state_size is increased in the 
future.
 
> > 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.

Probably this has been discussed extensively before (as you mentioned in 
some previous emails), but I missed the discussion and still have a naive 
question. Is delaying and batching possible for "wce=0", i.e., 
cache=writethrough? 

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