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