Re: [Qemu-devel] [PATCH] refresh filename after the node is replaced

[Max Reitz <mreitz@redhat.com>]

On 01.07.2015 03:08, Wen Congyang wrote:
> On 06/30/2015 09:17 PM, Max Reitz wrote:
>> On 29.06.2015 03:16, Wen Congyang wrote:
>>> On 06/26/2015 11:16 PM, Max Reitz wrote:
>>>> I see two solutions to this issue: Either, we do it right and that means, if there is a change in the BDS graph (e.g. because of bdrv_swap()),
>>>> we have to call bdrv_refresh_filename() on all of the changed BDS's parents. In order to be able to enumerate a BDS's parents, we need Kevin's
>>>> series, as said before.
>>> IIUC, the BDS can have more than one parent.
>> Indeed. Kevin's series adds a generalized parent-child relationship, which makes it possible to both enumerate all the children of a BDS and all its parents.
> How to get all its parents? Is this patch not merged into upstream?

The patch is actually already merged upstream 
(6e93e7c41fdfdee3068770cae79380e1d986b76a), but it does not add a way to 
enumerate a BDS's parents, only a BDS's children. It should not be too 
difficult to implement the reverse however, I guess, based on that patch.
Konsole output
>>>> Or we revive my series "block: Drop BDS.filename" which drops the BDS.filename field completely and always rebuilds it if it is queried.
>>>> This would fix the issue as well, however, there is a reason it has been lying around for nine months now, and that reason is that we did
>>>> not yet fully examine the impacts of dropping that field, especially concerning libvirt.
>>> If BDS.filename is dropped, this problem will go.
>> Right. But we have to make sure there won't be any negative impact if we do so, and because that is not really trivial, the series hasn't been applied yet and didn't receive further attention. Also, there was no real reason to do it other than "Because we can" until now. But I think the issue mentioned here is a good reason why we should indeed reconsider it.
> I don't find this series.

Maybe because it's pretty old. :-) I sent it last September: 
http://lists.nongnu.org/archive/html/qemu-devel/2014-09/msg04878.html

Max