Re: [RFC v2] external (pull) backup API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux