Re: [Qemu-block] [RFC] Re-evaluating subcluster allocation for qcow2 images

[Alberto Garcia]

I pressed "send" too early, here's the last part of my reply:

On Fri 28 Jun 2019 02:57:56 PM CEST, Alberto Garcia wrote:
>> I also ran some tests on a rotating HDD drive. Here having
>> subclusters doesn't make a big difference regardless of whether there
>> is a backing image or not, so we can ignore this scenario.

> Interesting, this is kind of unexpected. Why would avoided COW not
> make a difference on rotating HDDs? (All of this is cache=none,
> right?)

The 32K/4K with no COW is obviously much faster (it's also faster with
1MB and 2MB clusters), it's the rest of the scenarios that show no
improvement.

>> === Changes to the on-disk format ===
>> 
>> In my original proposal I described 3 different alternatives for
>> storing the subcluster bitmaps. I'm naming them here, but refer to
>> that message for more details.
>> 
>> (1) Storing the bitmap inside the 64-bit entry
>> (2) Making L2 entries 128-bit wide.
>> (3) Storing the bitmap somewhere else
>> 
>> I used (1) for this implementation for simplicity, but I think (2) is
>> probably the best one.
>
> Which would give us 32 bits for the subclusters, so you'd get 128k/4k
> or 2M/64k. Or would you intend to use some of these 32 bits for
> something different?

No, 32 bits for subclusters, or 64 if we don't have the 'all zeroes' bit
(we discussed this in a separate message).

> I think (3) is the worst because it adds another kind of metadata
> table that we have to consider for ordering updates. So it might come
> with more frequent cache flushes.

Yes I agree.

Berto