qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Mon, 14 Mar 2011 08:22:02 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

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.

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'm curious what other people think (Kevin/Stefan?).

Regards,

Anthony Liguori



reply via email to

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