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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4755 bytes --]

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 <mreitz@redhat.com>
>> ---
>>   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?

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]