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

[Kevin Wolf <kwolf@redhat.com>]

Am 14.03.2011 14:22, schrieb Anthony Liguori:
> On 03/13/2011 09:28 PM, Chunqiang Tang wrote:
>>>> In short, FVD's internal snapshot achieves the ideal properties of
>> G1-G6,
>>>> by 1) using the reference count table to only track "static"
>> snapshots, 2)
>>>> not keeping the reference count table in memory, 3) not updating the
>>>> on-disk "static" reference count table when the VM runs, and 4)
>>>> efficiently tracking dynamically allocated blocks by piggybacking on
>> FVD's
>>>> other features, i.e., its journal and small one-level lookup table.
>>> Are you assuming snapshots are read-only?
>>>
>>> It's not clear to me how this would work with writeable snapshots.  It's
>>> not clear to me that writeable snapshots are really that important, but
>>> this is an advantage of having a refcount table.
>>>
>>> External snapshots are essentially read-only snapshots so I can
>>> understand the argument for it.
>> By definition, a snapshot itself must be immutable (read-only), but a
>> writeable
>> image state can be derived from an immutable snapshot by using
>> copy-on-write,
>> which I guess is what you meant by "writeable snapshot."
> 
> No, because the copy-on-write is another layer on top of the snapshot 
> and AFAICT, they don't persist when moving between snapshots.
> 
> The equivalent for external snapshots would be:
> 
> base0 <- base1 <- base2 <- image
> 
> And then if I wanted to move to base1 without destroying base2 and 
> image, I could do:
> 
> qemu-img create -f qcow2 -b base1 base1-overlay.img
> 
> The file system can keep a lot of these things around pretty easily but 
> with your proposal, it seems like there can only be one.  If you support 
> many of them, I think you'll degenerate to something as complex as a 
> reference count table.

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.

> On the other hand, I think it's reasonable to just avoid the CoW overlay 
> entirely and say that moving to a previous snapshot destroys any of it's 
> children.  I think this ends up being a simplifying assumption that is 
> worth investigating further.
> 
>  From the use-cases that I'm aware of (backup and RAS), I think these 
> semantics are okay.

I don't think this semantics would be expected. Any anyway, would this
really allow simplification of the format? I'm afraid that you would go
for complicated solutions with odd semantics just because of an
arbitrary dislike of refcounts.

Kevin