qcow2: Document some maximum size constraints
authorEric Blake <eblake@redhat.com>
Thu, 15 Nov 2018 18:34:08 +0000 (12:34 -0600)
committerKevin Wolf <kwolf@redhat.com>
Mon, 19 Nov 2018 11:51:40 +0000 (12:51 +0100)
commitd3e1a7eb4ceb9489d575c45c9518137dfbd1389d
tree29e6352dfbacfee2dc6892158ddf7f1ec9ad083f
parent443ba6befa2f47243def9b190c930a8a4f59f888
qcow2: Document some maximum size constraints

Although off_t permits up to 63 bits (8EB) of file offsets, in
practice, we're going to hit other limits first.  Document some
of those limits in the qcow2 spec (some are inherent, others are
implementation choices of qemu), and how choice of cluster size
can influence some of the limits.

While we cannot map any uncompressed virtual cluster to any
address higher than 64 PB (56 bits) (due to the current L1/L2
field encoding stopping at bit 55), qemu's cap of 8M for the
refcount table can still access larger host addresses for some
combinations of large clusters and small refcount_order.  For
comparison, ext4 with 4k blocks caps files at 16PB.

Another interesting limit: for compressed clusters, the L2 layout
requires an ever-smaller maximum host offset as cluster size gets
larger, down to a 512 TB maximum with 2M clusters.  In particular,
note that with a cluster size of 8k or smaller, the L2 entry for
a compressed cluster could technically point beyond the 64PB mark,
but when you consider that with 8k clusters and refcount_order = 0,
you cannot access beyond 512T without exceeding qemu's limit of an
8M cap on the refcount table, it is unlikely that any image in the
wild has attempted to do so.  To be safe, let's document that bits
beyond 55 in a compressed cluster must be 0.

Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
docs/interop/qcow2.txt