Re: RFC: Qemu backup interface plans
25.05.2021 11:50, Max Reitz wrote:
On 19.05.21 08:11, Vladimir Sementsov-Ogievskiy wrote:
> 18.05.2021 19:39, Max Reitz wrote:
[...]
>> On 17.05.21 14:07, Vladimir Sementsov-Ogievskiy wrote:
[...]
>>> Not also, that there is another benefit of such thing: we'll implement
this callback in qcow2 driver, so that backup will read clusters not in guest cluster
order, but in host cluster order, to read more sequentially, which should bring better
performance on rotating disks.
>>
>> I’m not exactly sure how you envision this to work, but block_status also already
gives you the host offset in *map.
>>
>
> But block-status doesn't give a possibility to read sequentially. For this, user
should call block-status several times until the whole disk covered, then sort the
segments by host offset. I wonder, could it be implemented as some iterator, like
>
> read_iter = bdrv_get_sequential_read_iter(source)
>
> while (extents = bdrv_read_next(read_iter)):
> for ext in extents:
> start_writing_task(target, ext.offset, ext.bytes, ext.qiov)
>
> where bdrv_read_next will read guest data in host-cluster-sequence..
How would you implement this, though?
I don't know :) That's why I wrote "I wonder".. Anyway I have enough
work with all previous steps.
qcow2 doesn’t have a reverse mapping either, so it too would need to
read all L2 table entries and sort them, wouldn’t it?
Hmm, yes. With current qcow2, it seems to be the only way. And we'll be limited by
memory, so probably, read several L2 tables, do sort, return sorted extents, read next
bunch of L2 tables and so on.
And then, I agree, we can just implement with help of current block_status()
implementation.
Or probably we can implement reverse mapping in qcow2 as extension. But I doubt that it
worth the complexity.. Still, it depends on how much extra IO will it cost (almost
nothing, as should work through qcow2 cache) and how much performance benefit will it
bring (no idea, it should be measured).
--
Best regards,
Vladimir