Re: [Qemu-block] [PATCH 0/6] qcow2: Make the L2 cache cover the whole image by default

[Alberto Garcia]

On Mon 06 Aug 2018 01:30:33 PM CEST, Kevin Wolf wrote:
> Am 06.08.2018 um 13:07 hat Alberto Garcia geschrieben:
>> On Mon 06 Aug 2018 12:45:20 PM CEST, Kevin Wolf wrote:
>> > Am 06.08.2018 um 09:47 hat Alberto Garcia geschrieben:
>> >> On Fri 03 Aug 2018 04:55:42 PM CEST, Kevin Wolf wrote:
>> >> > By the way, weren't you working on subclusters a while ago? How did
>> >> > that go? Because I think those would enable us to use larger
>> >> > cluster sizes and therefore reduce the metadata sizes as well.
>> >> 
>> >> I had a working prototype, but the changes to both the code and the
>> >> on-disk format were not trivial. I would need to re-evaluate its
>> >> performance impact after all the changes that we have had since then,
>> >> and then see if it's worth trying again.
>> >> 
>> >> I suppose that the main benefit of having subclusters is that
>> >> allocations are much faster. Everything else remains more or less the
>> >> same, and in particular you can already use larger clusters if you
>> >> want to reduce the metadata sizes. Plus, with the l2-cache-entry-size
>> >> option you can already solve some of the problems of having large
>> >> clusters.
>> >
>> > Yes, indeed, subclusters are about making COW less painful (or getting
>> > rid of it altogether). Doing COW for full 2 MB when the guest updates
>> > 4k is just a bit over the top and I think it slows down initial writes
>> > seriously. I haven't benchmarked things in a while, though.
>> 
>> Me neither, I think the most recent ones that I have are from last year:
>> 
>> https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg01033.html
>> 
>> Since then we changed the cow algorithm to do only 2 operations instead
>> of 5, so that can affect the best case scenario.
>
> I can't find the numbers from the COW request merging any more, but I
> remember that when I tested the approach, the result was something
> like this: Merging the write requests pretty much got rid of any
> measurable COW overhead without a backing file, but as soon as you
> have to read from the backing file, the saved work isn't very
> significant any more and the cost of the read dominates.
>
> So when you test subclusters, be sure to not only test an empty
> standalone qcow2 image, but also a newly taken snapshot that has to
> COW from the backing file a lot.

Yes, that's the use case that I had in mind too.

Berto