qemu-block
[Top][All Lists]
Advanced

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

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


From: Alberto Garcia
Subject: Re: [PATCH v4 24/30] qcow2: Clear the L2 bitmap when allocating a compressed cluster
Date: Mon, 27 Apr 2020 20:12:13 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Mon 27 Apr 2020 09:49:00 AM CEST, Max Reitz wrote:
>> The point is this: Consider 'write -P 0xff 0 64k', then 'write -z 16k
>> 16k', then 'read 0 64k'. For normal clusters, we can just do a
>> scatter-gather iov read of read 0-16k and 32-64k, plus a memset of
>> 16-32k. But for compressed clusters, we have to read and decompress
>> the entire 64k, AND also memset 16k-32k. But if zeroing after reading
>> is not that expensive, then the same technique for normal clusters is
>> fine (instead of a scatter-gather read of 48k, just read the whole
>> 64k cluster before doing the memset).
>
> It would also mean letting qcow2_co_preadv_part() special-handle such
> cases, i.e., whenever the whole clusters is compressed, it needs to
> read it as a whole, regardless of the subcluster status, and then
> memset() all areas to zero that are all-zero subclusters.  Otherwise
> we’d read and decompress the whole buffer twice (once for 0 to 16k,
> once for 32k to 64k).

This is actually a good reason against adding subcluster allocation to
compressed clusters.

I wouldn't like to complicate the code for this use case, so we either
don't support it at all, or we support it with the problem that you
mention (decompressing the whole buffer more than once if the cluster
contains holes).

> Not sure how bad the complexity is on the write side for not letting
> zero writes just zero the subcluster

It is not bad, I just have to check the cluster type and return
-ENOTSUP.

Berto



reply via email to

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