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) -- Best regards, Vladimir