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
