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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
