[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 21:16:55 +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 20:23, schrieb 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. 

Okay, makes sense.

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

Yeah, that was a stupid decision, it definitely should be 64 bit.

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

It's possible with QED's approach: You set a dirty flag in the image
header, and while this flag is set you don't have to care about
consistent refcount tables. Only when you clear the flag, you must flush
the refcount cache to the image file.

If qemu crashes, you see the dirty flag and you know that you have an
image with stale refcounts. In this case you must do a metadata scan to
rebuild the refcount table from the L2 tables (or just replay the
journal if you have one).


reply via email to

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