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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

On 04/11/2017 09:31 AM, Alberto Garcia wrote:
> 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?

An internal snapshot causes a COW to happen if another write happens
anywhere in the cluster. Setting OFLAG_COPIED is a shorthand for whether
the COW must happen, but it is always possible (but slower) to refer
back to the refcount to learn the same information.  If we have a
cluster with missing subclusters, and need to do a COW, we are already
reading from the backing file - so we might as well populate the missing
subclusters of the original cluster at that time we write the new
updated cluster, at which point we no longer need to mark the cluster as
using subclusters.  Or we could state that the action of creating an
internal snapshot takes longer, because it fully populates all
partially-populated clusters (taking an internal snapshot is something
that is not done frequently, after all, as we've gradually been trying
to steer users to external snapshots) - or we could even go so far as to
state that internal snapshots and subclusters are incompatible (you
can't use both features at the same time).

It may be possible to make OFLAG_COPIED and subclusters work usefully
together, but the point being made here is that because we're already
changing design principles, we don't necessarily have to burn a bit on
OFLAG_COPIED if subclusters are in use.

> 
> 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?

I already think we're leaning away from option 1, even though the above
conversation was about how to pack more state into just 64 bits if we
wanted to stick with option 1.

If we use option 2 or 3, it may still be worth burning a bit in the
original 64 bits that says whether the subcluster secondary 64-bits is
valid (it might speed up some operations if we only have to do one
64-bit read and realize that the entire cluster is uniform, compared to
operations where the subcluster flag is set so we have to do a second
64-bit read to learn about the state of each subcluster).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]