Re: [Qemu-block] Performance impact of the qcow2 overlap checks

[Max Reitz]

On 25.01.2017 16:27, Alberto Garcia wrote:
> On Wed 25 Jan 2017 03:03:36 PM CET, Max Reitz wrote:
>>>> And of course another approach I already mentioned would be to scrap
>>>> the overlap checks altogether once we have image locking (and I
>>>> guess we can keep them around in their current form at least until
>>>> then).
>>>
>>> I think the overlap checks are fine, at least in my tests I only
>>> found problems with one of them, and only in some scenarios(*). So if
>>> we cannot optimize them easily I'd simply tell the user about the
>>> risks and suggest to disable them. Maybe the only thing that we need
>>> is simply good documentation.
>>
>> Well, overlap-check=none should be simple enough.
> 
> I was thinking more of a short document detailing the overlap checks,
> what they exactly do and how to disable them. It could go in the wiki /
> blog post. To be honest I only learnt about them (and that they're
> enabled by default) when I was profiling the qcow2 driver.

Yep, I just meant saying that "overlap-check=none should be simple
enough for a user to set".

Yes, a blog post would probably make sense. A wiki page would probably
imply having to create a qcow2 wiki page first. ;-)

>>> I think the most obvious candidate for optimization is
>>> refcount-block, and as I said it's the check what would create the
>>> bottleneck in most common scenarios. The optimization is simple: if
>>> the size of the qcow2 image is 7GB then you only need to check the
>>> first 4 entries in the refcount table.
>>>
>>> I can think of two problems with this, which is why I haven't sent a
>>> patch yet:
>>>
>>> (1) This needs the current size of the image every time we want to
>>>     perform that check, and that means I/O.
>>
>> Could be cached (every time some refcount is updated, you update a
>> max_refcounted_cluster variable in the qcow2 state), but that means
>> code.
> 
> That actually sounds simple enough. I can give it a try to see if it's
> worth doing, because I'd rather not do anything that needs too many
> changes.

Thanks!

Max

signature.asc
Description: OpenPGP digital signature