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 <mre...@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? >>> >> >> 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. Also, welcome back, congratulations, and all the best to your family! :-) Max
signature.asc
Description: OpenPGP digital signature