Re: [libvirt] [RFC v2] external (pull) backup API
On 04/23/2018 04:31 AM, Vladimir Sementsov-Ogievskiy wrote:
> And if there is more than one bitmap on snap1, do we
> need to bring all of those bitmaps forward into snap2, or just the one
> that was currently active?
Again, I think, to make snapshots unrelated, it's better to keep them
all. Let disk snapshot to be a snapshot of dirty-bitmaps too.
So that means creating a new external snapshot (a new qcow2 wrapper)
should copy all existing bitmaps from the backing file into the new
active layer?
> Similarly, if we later decide to live commit
> snap2 back into snap1, we'll want to merge the changes in snap2.B2 back
> into snap1.B1 (now that snap1 is once again active, it needs to track
> all changes that were merged in, and all future changes until the next
> snapshot).
And here we will just drop older versions of bitmaps.
> Which means we need to at least be thinking about cross-node
> snapshot merges,
hmm, what is it?
By "cross-node snapshot merge", I meant the situation where we have:
base <- snap1 (containing bitmap B1) <- snap2 (containing bitmap B2)
If we need to create a bitmap containing the merge of B1 and B2, whether
that new bitmap B3 is stored in snap1 or in snap2, we are doing a
cross-node merge (because the two source bitmaps in the merge live on
different nodes of the backing chain).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)