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 <[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) > > 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
