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 <[email protected]> >>>> --- >>>> 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) > >
Strange, I have this mail automatically returned back. Did you receive it? -- Best regards, Vladimir
