Re: [Qemu-devel] [PATCH 0/2] deal with BDRV_BLOCK_RAW

[Vladimir Sementsov-Ogievskiy]

13.08.2019 11:39, Vladimir Sementsov-Ogievskiy wrote:
> 12.08.2019 22:50, Max Reitz wrote:
>> On 12.08.19 21:46, Max Reitz wrote:
>>> On 12.08.19 20:11, Vladimir Sementsov-Ogievskiy wrote:
>>>> Hi all!
>>>>
>>>> I'm not sure, is it a bug or a feature, but using qcow2 under raw is
>>>> broken. It should be either fixed like I propose (by Max's suggestion)
>>>> or somehow forbidden (just forbid backing-file supporting node to be
>>>> file child of raw-format node).
>>>
>>> I agree, I think only filters should return BDRV_BLOCK_RAW.
>>>
>>> (And not even them, they should just be handled transparently by
>>> bdrv_co_block_status().  But that’s something for later.)
>>>
>>>> Vladimir Sementsov-Ogievskiy (2):
>>>>    block/raw-format: switch to BDRV_BLOCK_DATA with BDRV_BLOCK_RECURSE
>>>>    iotests: test mirroring qcow2 under raw format
>>>>
>>>>   block/raw-format.c         |  2 +-
>>>>   tests/qemu-iotests/263     | 46 ++++++++++++++++++++++++++++++++++++++
>>>>   tests/qemu-iotests/263.out | 12 ++++++++++
>>>>   tests/qemu-iotests/group   |  1 +
>>>>   4 files changed, 60 insertions(+), 1 deletion(-)
>>>>   create mode 100755 tests/qemu-iotests/263
>>>>   create mode 100644 tests/qemu-iotests/263.out
>>>
>>> Thanks, applied to my block-next branch:
>>>
>>> https://git.xanclic.moe/XanClic/qemu/commits/branch/block-next
>>
>> Oops, maybe not.  221 needs to be adjusted.
>>
> 
> 
> Hmm yes, I forget to run tests.. Areas which were zero becomes data|zero, it
> don't look good.
> 
> So, it's not quite right to report DATA | RECURSE, we actually should report
> DATA_OR_ZERO | RECURSE, which is actually ALLOCATED | RECURSE, as otherwise
> DATA will be set in final result (generic layer must not drop it, obviously).
> 
> ALLOCATED never returned by drivers but seems it should be. I'll think a bit 
> and
> resend something new.
> 
> 


Hmmm.. So, we have raw node, and assume backing chain under it. who should loop 
through it,
generic code or raw driver?

Now it all looks like generic code is responsible for looping through filtered 
chain (backing files
and filters) and driver is responsible for all it's children except for 
filtered child.

Or, driver may return something that says to generic child to handle the whole 
backing chain of returned
file at once, as it's another backing chain. And seems even RECURSE don't work 
correctly as it doesn't handle
the backing chain in this recursion. Why it works better than RAW - just 
because we return it together
with DATA flags and this DATA flag is kept anyway, independently of finding 
zeros or not.


-- 
Best regards,
Vladimir