Re: [PATCH 3/9] util: storage: Store backing chain index in virStorageSource

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

 



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

[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