Re: [Qemu-devel] [PATCH 8/8] docs: document how to configure the qcow2 L2/refcount caches

[Max Reitz <mreitz@redhat.com>]

On 11.05.2015 15:30, Alberto Garcia wrote:
> On Mon 11 May 2015 03:23:25 PM CEST, Max Reitz <mreitz@redhat.com> wrote:
>
>>> +   disk_size = l2_cache_size * cluster_size / 8
>>> +   disk_size = refcount_cache_size * cluster_size / 2
>> Only with the default of refcount_bits=16. In the general case, it's
>> refcount_cache_size * cluster_size * 8 / refcount_bits.
> I actually omitted that on purpose because I didn't want to go into too
> many details and I hadn't realized that it's now possible to configure
> refcount_bits. I will correct the document.
>
> I wonder what happens then to this DEFAULT_L2_REFCOUNT_SIZE_RATIO of 4,
> because that's only valid if refcount_bits == 16.
>
> Is the user supposed to calculate that ratio manually and configure both
> cache sizes?

Well... Considering nobody will probably ever use refcount_bits > 16, we 
don't need to worry about 4 being too big of a ratio. And I think, for 
cases of refcount_bits < 16, we wouldn't really save as much to justify 
adjusting the ratio. So while it would be possible to make qcow2 choose 
a variable ratio based on refcount_bits, I don't think we really need to 
care about it.

But as for the user, I do think they should care about it, or at least 
know about it. If they are already adjusting the cache sizes manually, 
they should know exactly what the ratio should be. For justifying why 
qemu does not adjust its default ratio, I think it's enough to write 
that that default ratio (4) is geared towards the default value of 
refcount_bits (16) and that should be enough.

If we do decide to implement a variable ratio later on, we can still 
change this documentation.

Oh, and also note that the "range covered" by the metadata caches are 
different things: For the L2 tables, it's a guest offset range, while 
for the refblocks it's a host offset range. Also, you basically only 
need the refcounts for allocating clusters and doing internal snapshot 
operations (you don't need them for reads, and you don't need them for 
non-allocating writes, thanks to the O_COPIED flag), so it would 
actually make sense for the user to choose a ratio larger than 64 / 
refcount_bits because refcounts are (1) rarely ever needed, and (2) when 
they are needed, they are most likely for allocation, which most likely 
will occur at the image's end (unless you're using internal snapshots or 
you're manually discarding things), so you actually only need to cache 
the refblock covering the image end.

Max

>
>> Apart from this minor thing, looks good. Well, except that maybe it
>> should be preferred to use .qcow2 as the extension for qcow2 files
>> (instead of .img).
> Sure, I can change that too.
>
> Berto