[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: |
Wed, 24 Jul 2019 09:54:24 +0000 |
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 <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)
>
>
Strange, I have this mail automatically returned back. Did you receive it?
--
Best regards,
Vladimir
- Re: [Qemu-block] [PATCH v5 30/42] qemu-img: Use child access functions,
Vladimir Sementsov-Ogievskiy <=