qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alberto Garcia
Subject: Re: [Qemu-block] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Wed, 12 Apr 2017 14:41:55 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Tue 11 Apr 2017 04:45:29 PM CEST, Eric Blake 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.

I still don't see why we can always assume OFLAG_COPIED. Before doing
the COW one cluster can have references from multiple snapshots, and
OFLAG_COPIED is equally valid in that context. We still need to know if
we need to perform COW when writing to it, regardless of whether it has
subclusters or not.

Also, when doing a COW for an internal snapshot we definitely have to
duplicate the whole cluster, but do we really need to read from the
backing file? Can't we leave the missing subclusters unallocated in the
copy?

> 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).

Yeah, that might be a good idea.

Berto



reply via email to

[Prev in Thread] Current Thread [Next in Thread]