[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v5 30/42] qemu-img: Use child access functions
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
Re: [Qemu-block] [PATCH v5 30/42] qemu-img: Use child access functions |
Date: |
Fri, 21 Jun 2019 13:15:08 +0000 |
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 <address@hidden>
>>> ---
>>> 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
[Qemu-block] [PATCH v5 35/42] block: Fix check_to_replace_node(), Max Reitz, 2019/06/12
[Qemu-block] [PATCH v5 34/42] block: Inline bdrv_co_block_status_from_*(), Max Reitz, 2019/06/12
[Qemu-block] [PATCH v5 36/42] iotests: Add tests for mirror @replaces loops, Max Reitz, 2019/06/12
[Qemu-block] [PATCH v5 38/42] iotests: Let complete_and_wait() work with commit, Max Reitz, 2019/06/12
[Qemu-block] [PATCH v5 39/42] iotests: Add filter commit test cases, Max Reitz, 2019/06/12
[Qemu-block] [PATCH v5 37/42] block: Leave BDS.backing_file constant, Max Reitz, 2019/06/12