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

[Kevin Wolf]

Am 28.06.2019 um 15:19 hat Alberto Garcia geschrieben:
> 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.

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.

Another thing to consider is that with two bits per subcluster, we'd
still have one combination left for other purposes (we only have
unallocated, allocated, zero). In previous discussions, we talked about
the possibility of using that for a new "write-through to backing file"
cluster type. It's not clear if this is a good idea, but it came up
multiple times in the past.

Kevin