[Top][All Lists]

[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: 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
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
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
image state can be derived from an immutable snapshot by using
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?).


Anthony Liguori

reply via email to

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