[Top][All Lists]

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

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

From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 8/8] docs: document how to configure the qcow2 L2/refcount caches
Date: Mon, 11 May 2015 16:08:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 11.05.2015 15:30, Alberto Garcia wrote:
On Mon 11 May 2015 03:23:25 PM CEST, Max Reitz <address@hidden> 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.


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.


reply via email to

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