Re: [Qemu-block] [PATCH v5 30/42] qemu-img: Use child access functions

[Vladimir Sementsov-Ogievskiy]

25.07.2019 19:34, Max Reitz wrote:
> On 24.07.19 11:54, Vladimir Sementsov-Ogievskiy wrote:
>> 21.06.2019 16:15, Vladimir Sementsov-Ogievskiy wrote:
>>> 19.06.2019 18:49, Max Reitz wrote:
>>>> On 19.06.19 11:18, Vladimir Sementsov-Ogievskiy wrote:
>>>>> 13.06.2019 1:09, Max Reitz wrote:
>>>>>> This changes iotest 204's output, because blkdebug on top of a COW node
>>>>>> used to make qemu-img map disregard the rest of the backing chain (the
>>>>>> backing chain was broken by the filter).  With this patch, the
>>>>>> allocation in the base image is reported correctly.
>>>>>>
>>>>>> Signed-off-by: Max Reitz <address@hidden>
>>>>>> ---
>>>>>>     qemu-img.c                 | 36 ++++++++++++++++++++----------------
>>>>>>     tests/qemu-iotests/204.out |  1 +
>>>>>>     2 files changed, 21 insertions(+), 16 deletions(-)
>>>>>>
>>>>>> diff --git a/qemu-img.c b/qemu-img.c
>>>>>> index 07b6e2a808..7bfa6e5d40 100644
>>>>>> --- a/qemu-img.c
>>>>>> +++ b/qemu-img.c
>>>>>> @@ -992,7 +992,7 @@ static int img_commit(int argc, char **argv)
>>>>>>         if (!blk) {
>>>>>>             return 1;
>>>>>>         }
>>>>>> -    bs = blk_bs(blk);
>>>>>> +    bs = bdrv_skip_implicit_filters(blk_bs(blk));
>>>>>
>>>>> if filename is json, describing explicit filter over normal node, bs will 
>>>>> be
>>>>> explicit filter ...
>>>>>
>>>>>>         qemu_progress_init(progress, 1.f);
>>>>>>         qemu_progress_print(0.f, 100);
>>>>>> @@ -1009,7 +1009,7 @@ static int img_commit(int argc, char **argv)
>>>>>>             /* This is different from QMP, which by default uses the 
>>>>>> deepest file in
>>>>>>              * the backing chain (i.e., the very base); however, the 
>>>>>> traditional
>>>>>>              * behavior of qemu-img commit is using the immediate 
>>>>>> backing file. */
>>>>>> -        base_bs = backing_bs(bs);
>>>>>> +        base_bs = bdrv_filtered_cow_bs(bs);
>>>>>>             if (!base_bs) {
>>>>>
>>>>> and here we'll fail.
>>>>
>>>> Right, will change to bdrv_backing_chain_next().
>>>>
>>>>>>                 error_setg(&local_err, "Image does not have a backing 
>>>>>> file");
>>>>>>                 goto done;
>>>>>> @@ -1626,19 +1626,18 @@ static int 
>>>>>> convert_iteration_sectors(ImgConvertState *s, int64_t sector_num)
>>>>>>         if (s->sector_next_status <= sector_num) {
>>>>>>             int64_t count = n * BDRV_SECTOR_SIZE;
>>>>>> +        BlockDriverState *src_bs = blk_bs(s->src[src_cur]);
>>>>>> +        BlockDriverState *base;
>>>>>>             if (s->target_has_backing) {
>>>>>> -
>>>>>> -            ret = bdrv_block_status(blk_bs(s->src[src_cur]),
>>>>>> -                                    (sector_num - src_cur_offset) *
>>>>>> -                                    BDRV_SECTOR_SIZE,
>>>>>> -                                    count, &count, NULL, NULL);
>>>>>> +            base = bdrv_backing_chain_next(src_bs);
>>>>>
>>>>> As you described in another patch, will not we here get allocated in base 
>>>>> as allocated, because of
>>>>> counting filters above base?
>>>>
>>>> Damn, yes.  So
>>>>
>>>>       base = bdrv_filtered_cow_bs(bdrv_skip_rw_filters(src_bs));
>>>>
>>>> I suppose.
>>>>
>>>>> Hmm. I now think, why filters don't report everything as unallocated, 
>>>>> would not it be more correct
>>>>> than fallthrough to child?
>>>>
>>>> I don’t know, actually.  Maybe, maybe not.
>>>>
>>>>>>             } else {
>>>>>> -            ret = bdrv_block_status_above(blk_bs(s->src[src_cur]), NULL,
>>>>>> -                                          (sector_num - src_cur_offset) 
>>>>>> *
>>>>>> -                                          BDRV_SECTOR_SIZE,
>>>>>> -                                          count, &count, NULL, NULL);
>>>>>> +            base = NULL;
>>>>>>             }
>>>>>> +        ret = bdrv_block_status_above(src_bs, base,
>>>>>> +                                      (sector_num - src_cur_offset) *
>>>>>> +                                      BDRV_SECTOR_SIZE,
>>>>>> +                                      count, &count, NULL, NULL);
>>>>>>             if (ret < 0) {
>>>>>>                 error_report("error while reading block status of sector 
>>>>>> %" PRId64
>>>>>>                              ": %s", sector_num, strerror(-ret));
>>>>
>>>> [...]
>>>>
>>>>>> @@ -2949,7 +2950,7 @@ static int img_map(int argc, char **argv)
>>>>>>         if (!blk) {
>>>>>>             return 1;
>>>>>>         }
>>>>>> -    bs = blk_bs(blk);
>>>>>> +    bs = bdrv_skip_implicit_filters(blk_bs(blk));
>>>>>
>>>>> Hmm, another thought about implicit filters, how they could be here in 
>>>>> qemu-img?
>>>>
>>>> Hm, I don’t think they can.
>>>>
>>>>> If implicit are only
>>>>> job filters. Do you prepared it for implicit COR? But we discussed with 
>>>>> Kevin that we'd better deprecate
>>>>> copy-on-read option..
>>>>>
>>>>> So, if implicit filters are for compatibility, we'll have them only in 
>>>>> block-jobs. So, seems no reason to support
>>>>> them in qemu-img.
>>>>
>>>> Seems reasonable, yes.
>>>>
>>>>> Also, in block-jobs, we can abandon creating implicit filters above any 
>>>>> filter nodes, as well as abandon creating any
>>>>> filter nodes above implicit filters. This will still support old 
>>>>> scenarios, but gives very simple and well defined scope
>>>>> of using implicit filters and how to work with them. What do you think?
>>>>
>>>> Hm, in what way would that make things simpler?
>>>>
>>>
>>> This question was in my mind while I've finishing this paragraph) At least 
>>> such restriction answer the question, where
>>> should new filters be added: below or under implicit filters.. With such 
>>> restriction we always can have only one implicit filter
>>> over non-filter node, and above it should be explicit filter or non-filter 
>>> node. But this need huge work to be done with small
>>> benefit, so, forget it)
> 
> OK.  I should have read the last part first, then I could have replied
> sooner. :-)
> 
>> Strange, I have this mail automatically returned back. Did you receive it?
> 
> No, I didn’t.  (Nor any of the other mails you resent.)  Weird.

Interesting that it reached mailing list and presents in archive.

> 
> Also, welcome back, congratulations, and all the best to your family! :-)
> 


Thank you!


-- 
Best regards,
Vladimir