On 10/13/2017 12:43 AM, Peter Krempa wrote: > On Thu, Oct 12, 2017 at 14:57:36 -0500, Eric Blake wrote: >> On 10/12/2017 02:07 PM, Peter Krempa wrote: >>> The backing store indexes were not bound to the storage sources in any >>> way. To allow us to bind a given alias to a given storage source we need >>> to save the index in virStorageSource. The backing store ids are now >>> generated when detecting the backing chain. >>> >>> Since we don't re-detect the backing chain after snapshots, the >>> numbering needs to be fixed there. >>> --- >> Is renumbering going to affect API? >> >> It's the difference between starting with: >> >> back <- mid <- active >> >> having numbers 3, 2, 1, vs. starting with: >> >> back <- mid >> >> then creating active via snapshot, and now having numbers 2, 1, 3. > > In case when we will not use blockdev-add, the order will be 1,2,3 > always, since they will be in order. If blockdev add will be used it > should be 4,1,3, so if you pop out 2 of the chain, it will never appear > back. > >> >> In other words, do we try to preserve that index 1 is tied to the file >> we opened first, no matter what order it is currently in the chain, or >> do we state that our use of "vda[1]" to denote a member of the chain may >> mean different files at different points in time based on what other >> chain manipulations have caused renumbering along the way? > > Exactly, but possible only when tracking the full chain. > >> >> When we were always regenerating the chain on the fly, there wasn't much >> stability to worry about. But now that we are going to try to preserve >> the index across domain reboots, we need to make sure we know which way >> we want things to work. > > I don't really want to go as far as guaranteeing the numbers across > reboots. I think keeping them across one lifetime should be good enough. Unless anyone else has strong opinions about disk indices not always being stable, I can live with this as your design goal. As I mentioned in 4/9, I didn't see anything wrong with the code itself, so as long as we don't have a problem with the design implications: Reviewed-by: Eric Blake <eblake@xxxxxxxxxx> -- 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
