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