qemu-devel
[Top][All Lists]
Advanced

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

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


From: Max Reitz
Subject: Re: [Qemu-devel] [Qemu-block] [RFC] Proposed qcow2 extension: subcluster allocation
Date: Wed, 12 Apr 2017 16:10:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

On 12.04.2017 14:41, Alberto Garcia wrote:
> 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,

Yes...

>                                                                  and
> OFLAG_COPIED is equally valid in that context.

In what context? When having subclusters? Why?

>                                                We still need to know if
> we need to perform COW when writing to it, regardless of whether it has
> subclusters or not.

But why would you reference a cluster multiple times if it has
subclusters? Yes, you can do it in theory, but we could just disallow
it, because it doesn't make sense.

As I've said before, there may be uses for clusters to be referenced
multiple times other than internal snapshots; but right now we only use
it for internal snapshots, and I don't think that disallowing multiple
references for subclustered clusters would be horrible for any of the
other use cases.

> 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?
Can't we just disallow !OFLAG_COPIED for subclustered clusters?

To me it seems you implicitly assume we would want to allow
!OFLAG_COPIED, and based on that you argue how we could do so and what
semantics it would bear. However, I fail to see why we would want that
feature at all.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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