[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 15:34:11 +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 15:25, schrieb Chunqiang Tang:
>> IIUC, he already uses a refcount table. Actually, I think that a
>> refcount table is a requirement to provide the interesting properties
>> that internal snapshots have (see my other mail).
>> Refcount tables aren't a very complex thing either. In fact, it makes a
>> format much simpler to have one concept like refcount tables instead of
>> adding another different mechanism for each new feature that would be
>> natural with refcount tables.
>> The only problem with them is that they are metadata that must be
>> updated. However, I think we have discussed enough how to avoid the
>> greatest part of that cost.
> 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.

Yeah, I think that's basically an interesting property. However, I don't
think that it makes a big difference compared to qcow2's refcount table
when you use a writeback metadata cache.

What about the question that I had in my other mail? (How do you
determine if a cluster is free without scanning the whole lookup table?)
I think this might be the missing piece for me to understand how your
approach works.


reply via email to

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