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

[Alberto Garcia]

On Fri 28 Jun 2019 04:16:28 PM CEST, Kevin Wolf wrote:
>> >> >> >> I would consider 64k cluster/8k subcluster as too extreme
>> >> >> >> for me.
>> >> >> 
>> >> >> I forgot to add: this 64k/8k ratio is only with my current
>> >> >> prototype.
>> >> >> 
>> >> >> In practice if we go with the 128-bit L2 entries we would have
>> >> >> 64 subclusters per cluster, or 32 if we want to have a separate
>> >> >> QCOW_OFLAG_ZERO for each subcluster (would we need this?).
>> >> >
>> >> > Yes, I think we'd want to have a separate zero flag for each
>> >> > subcluster.  Otherwise, when writing to a zero cluster, you'd
>> >> > have to COW the whole supercluster again.
>> >> 
>> >> Yes if the original cluster had the QCOW_OFLAG_ZERO bit, not if it
>> >> was simply unallocated.
>> >
>> > Right, but that leaving clusters simply unallocated doesn't quite
>> > cut it is something we already noticed before writing the spec for
>> > v3. Only really necessary when you have a backing file, of course,
>> > but that's one of the more interesting cases for subclusters
>> > anyway.
>> 
>> I wonder if it would be possible to have a hybrid solution:
>> 
>> With 64 bits to indicate the allocation status of each subcluster we
>> still have the original L2 entry with its QCOW_OFLAG_ZERO bit, so we
>> need to specify what happens if that bit is set and at the same time
>> some subclusters are marked as allocated.
>> 
>> One possibility is that allocated subclusters have actual data and
>> the rest are zero subclusters.
>
> Hm, yes, that would be possible.
>
> However, that would require some addtional complexity in write_zeroes
> then: If the zero flag isn't set yet, then we need to check that no
> other subcluster is unallocated before we can turn the zero flag on
> for the whole cluster. You couldn't have subclusters referring to the
> backing file and zeroed subclusters at the same time.
>
> Maybe doubling the number of bits would actually be worth the
> additional complexity in write_zeroes.

Yes, that's a bit my doubt. How important it is to have those features
that you mention vs being able to halve the minimum unit of allocation.

Berto