qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [RFC] Re-evaluating subcluster allocation for qcow2 ima


From: Alberto Garcia
Subject: Re: [Qemu-block] [RFC] Re-evaluating subcluster allocation for qcow2 images
Date: Fri, 28 Jun 2019 15:19:38 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Fri 28 Jun 2019 12:04:22 PM CEST, Kevin Wolf wrote:
> Am 28.06.2019 um 11:53 hat Alberto Garcia geschrieben:
>> On Fri 28 Jun 2019 11:20:57 AM 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.

Berto



reply via email to

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