Re: [PATCH v4 24/30] qcow2: Clear the L2 bitmap when allocating a compressed cluster

[Eric Blake <eblake@redhat.com>]

On 4/24/20 12:02 PM, Alberto Garcia wrote:
> On Tue 17 Mar 2020 07:16:21 PM CET, Alberto Garcia <berto@igalia.com> wrote:
>> Compressed clusters always have the bitmap part of the extended L2
>> entry set to 0.
> 
> I was just finishing some improvements to the new code that allows
> BDRV_REQ_ZERO_WRITE at the subcluster level, and I'm starting to
> entertain the idea of using the L2 bitmap for compressed clusters as
> well.
> 
> I will make some tests next week, but I would like to know your opinion
> in case I'm missing something.
> 
> A compressed cluster cannot be divided into subclusters on the image:
> you would not be able to allocate or overwrite them separately,
> therefore any write request necessarily has to write (or do COW of) the
> whole cluster.
> 
> However if you consider the uncompressed guest data I don't see any
> reason why you wouldn't be able to zeroize or even deallocate individual
> subclusters. These operations don't touch the cluster data on disk
> anyway, they only touch the L2 metadata in order to change what the
> guest sees.
> 
> 'write -c 0 64k' followed by 'write -z 16k 16k' would not need to do any
> copy on write. The compressed data would remain untouched on disk but
> some of the subclusters would have the 'all zeroes' bit set, exactly
> like what happens with normal clusters.

It's a special case that avoids COW for write zeroes, but not for 
anything else. The moment you write any data (whether to the 
zero-above-compressed or the regular compressed portion), the entire 
cluster has to be rewritten.  I'm not sure how frequently guests will 
actually have the scenario of doing a zero request on a sub-cluster, but 
at the same time, I can see where you're coming from in stating that if 
it makes management of extended L2 easier to allow zero subclusters on 
top of a compressed cluster, then there's no reason to forbid it.

> 
> I think that this would make the on-disk format a bit simpler in general
> (no need to treat compressed clusters differently in some cases) and it
> would add a new optimization to compressed images. I just need to make
> sure that it doesn't complicate the code (my feeling is that it would
> actually simplify it, but I have to see).
> 
> Opinions?
> 
> Berto
> 

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