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

[Vladimir Sementsov-Ogievskiy]

24.04.2020 20:44, Eric Blake wrote:
> On 4/24/20 12:21 PM, Alberto Garcia wrote:
> > On Fri 24 Apr 2020 07:11:08 PM CEST, Eric Blake <address@hidden> wrote:
> > > > '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.
> >
> > That's right but you can still write zeroes without having to rewrite
> > anything, and read back the zeroes without having to decompress the
> > data.
> >
> > > 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'm not sure if it makes it easier. Some operations are definitely going
> > to be easier but maybe we have to add and handle _ZERO_COMPRESSED in
> > addition to _ZERO_PLAIN and _ZERO_ALLOC (the same for unallocated
> > subclusters). Or maybe replace QCow2SubclusterType with something
> > else. I need to evaluate that.
>
> Reading the entire cluster will be interesting - you'll have to decompress the 
> entire memory, then overwrite the zeroed portions.  The savings in reading 
> occur only when your read is limited to just the subclusters that are zeroed.
>
> But then again, even on a regular cluster, read has to pay attention to which 
> subclusters are zeroed, so you already have the workhorse in read for detecting 
> whether a normal read is sufficient or if you have to follow up with piecing 
> together zeroed sections.

AFAIK, now compressed clusters can't be used in scenarios with guest, as qcow2 
driver doesn't support rewriting them. Or am I wrong? And we normally don't 
combine normal and compressed clusters together in one image. So, currently, 
the usual use-case of compressed clusters is a fully compressed image, written 
once.

It means, that with current specification, subclusters adds nothing to this 
case, and no reason to create compressed image with subclusters. And even if we 
allow zero/unallocated subclusters, seems it adds nothing to this use-case.

So, I don't see real benefits of it for now, but neither any problems with it, 
so agree that it's mostly about which way is simpler..

--
Best regards,
Vladimir