Re: [Qemu-devel] [RFC] Proposed qcow2 extension: subcluster allocation

[Alberto Garcia <berto@igalia.com>]

On Tue 11 Apr 2017 04:04:53 PM CEST, Max Reitz wrote:
>>> (We could even get one more bit if we had a subcluster-flag, because I
>>> guess we can always assume subclustered clusters to have OFLAG_COPIED
>>> and be uncompressed. But still, three bits missing.)
>> 
>> Why can we always assume OFLAG_COPIED?
>
> Because partially allocated clusters cannot be used with internal
> snapshots, and that is what OFLAG_COPIED is for.

Why can't they be used?

>>> If course, if you'd be willing to give up the all-zeroes state for
>>> subclusters, it would be enough...
>> 
>> I still think that it looks like a better idea to allow having more
>> subclusters, but giving up the all-zeroes state is a valid
>> alternative. Apart from having to overwrite with zeroes when a
>> subcluster is discarded, is there anything else that we would miss?
>
> It if it's a real discard you can just discard it (which is what we do
> for compat=0.10 images anyway); but zero-writes will then have to be
> come real writes, yes.

Perhaps we can give up that bit for subclusters then, that would allow
us to double their number. We would still have the zero flag at the
cluster level. Opinions on this, anyone?

>>> By the way, if you'd only allow multiple of 1s overhead
>>> (i.e. multiples of 32 subclusters), I think (3) would be pretty much
>>> the same as (2) if you just always write the subcluster information
>>> adjacent to the L2 table. Should be just the same caching-wise and
>>> performance-wise.
>> 
>> Then (3) is effectively the same as (2), just that the subcluster
>> bitmaps are at the end of the L2 cluster, and not next to each entry.
>
> Exactly. But it's a difference in implementation, as you won't have to
> worry about having changed the L2 table layout; maybe that's a
> benefit.

I'm not sure if that would simplify or complicate things, but it's worth
considering.

Berto