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