Re: [Qemu-devel] [PATCH v4 2/5] qcow2: Document some maximum size constraints

[Eric Blake]

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