Re: [Qemu-block] [PATCH RFC 0/1] Allow storing the qcow2 L2 cache in disk

[Alberto Garcia]

On Tue 13 Dec 2016 02:44:26 PM CET, Max Reitz wrote:

>>>> But leaving that aside, would that improve anything? I don't think
>>>> the cache itself adds any significant overhead here, IIRC even in
>>>> your presentation at KVM Forum 2015 qcow2 was comparable to raw as
>>>> long as all L2 tables were cached in memory.
>>>
>>> I haven't compared CPU usage, though. That may have gone up quite a
>>> bit, I don't know. For large enough images, it may even become a
>>> bottleneck.
>>
>> I don't know, I don't have any data to suggest that there's a problem
>> there, particularly after the rewrite from last year I think the
>> cache is reasonably fast (as long as the cache is big enough; and if
>> it's not big enough the problem is going to be in the extra I/O).
>
> So the remaining question is whether we want a cache for the cache. If
> the cache is stored directly on an SSD, any access to it has to go
> there and back, and that seems like we may still want to have the
> option of having an in-RAM cache on top of it.

That would be indeed possible... but I wouldn't have any without data
showing that it's worth it.

> If we don't want to split the qcow2 file into separate metadata and
> data files, then we could still create a sparse temporary file at
> runtime which contains all L2 tables. Reading an L2 table then
> wouldn't go through the qcow2 file but through that temporary file and
> our existing metadata cache would work on top of it.

And if you modify a table you have to do it in both places.

The basic idea is the same, anyway. I just started with the assumption
that the L2 cache structures don't add significant overhead and went for
the simplest solution (that's why it's an RFC after all).

But implementation details aside, the main question is whether the best
way to go is to keep the existing metadata and store it in a faster disk
or, as Stefan suggested, think about replacing the current structures
with something else that scales better. I think that's at least worth
exploring.

Berto