[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 30/42] qemu-img: Use child access functions
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [PATCH v5 30/42] qemu-img: Use child access functions |
Date: |
Thu, 25 Jul 2019 18:34:12 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 |
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 <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)
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.
Also, welcome back, congratulations, and all the best to your family! :-)
Max
signature.asc
Description: OpenPGP digital signature