qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH] qcow2: Optimize the refcount-block overlap chec


From: Alberto Garcia
Subject: Re: [Qemu-block] [PATCH] qcow2: Optimize the refcount-block overlap check
Date: Wed, 01 Feb 2017 11:39:56 +0100
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Wed 01 Feb 2017 02:46:20 AM CET, Max Reitz <address@hidden> wrote:

>> The problem with the refcount table is that since it always occupies
>> complete clusters its size is usually very big.
>
> Actually the main problem is that BDRVQcow2State.refcount_table_size
> is updated very generously as opposed to BDRVQcow2State.l1_size. The
> latter is usually exactly as large as it needs to be (because the L1
> table size usually doesn't change), whereas the refcount_table_size is
> just bumped up every time the image gets bigger until it reaches or
> exceeds the value it needs to be.

That's actually a good point.

One reason why this happens is that the size of the L1 table is static
and the qcow2 header stores the actual number of entries, whereas for
the refcount table it stores the number of clusters.

Maybe we can have refcount_table_size store the actual size of the
table. The number of clusters can be calculated from that after all, and
we would get rid of max_refcount_table_index.

The change might be a bit more difficult, though, I'll take a look.

>> @@ -439,6 +450,7 @@ static int alloc_refcount_block(BlockDriverState *bs,
>>          }
>>  
>>          s->refcount_table[refcount_table_index] = new_block;
>> +        s->max_refcount_table_index = refcount_table_index;
>
> Should be MAX(s->max_refcount_table_index, refcount_table_index) or
> this won't support refcount tables with holes in them.

Good catch.

Berto



reply via email to

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