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@redhat.com> -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org