On 02/28/2018 04:26 AM, Alberto Garcia wrote:
On Tue 27 Feb 2018 05:29:41 PM CET, Eric Blake wrote:
+The refcount table has implications on the maximum host file size; a
+larger cluster size is required for the refcount table to cover
larger +offsets.
Why is this? Because of the refcount_table_clusters field ?
I think the maximum offset allowed by that is ridiculously high,
exceeding any other limit imposed by the L1/L2 tables.
Good point. I was basing my comment off of qcow2.h:
/* 8 MB refcount table is enough for 2 PB images at 64k cluster size
* (128 GB for 512 byte clusters, 2 EB for 2 MB clusters) */
#define QCOW_MAX_REFTABLE_SIZE 0x800000
But that's our implementation choice (we put a maximum amount of memory
on the size of the refcount table we are willing to support, while the
qcow2 spec would allow an implementation willing to reserve more memory
to access even larger sizing).
If my numbers are right, with the default values that's 64 ZB.
In addition to that, the size that can be covered by the refcount table
also depends on the size of refcount entries (refcount_order).
True.
With 512 byte clusters and 64 bit refcount entries I still get 8 PB, way
over what's limited by the L1/L2 tables (128 GB).
Do I need to make any modifications to the sentence, then? Or is it
still accurate, if vague, to leave the sentence as is because there IS
an impact to consider, even if the impact is unlikely to matter in
relation to other sizing impacts?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
