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? Max
signature.asc
Description: OpenPGP digital signature