aboutsummaryrefslogtreecommitdiff
path: root/block/qcow2.h
diff options
context:
space:
mode:
authorEric Blake <eblake@redhat.com>2018-11-15 12:34:08 -0600
committerKevin Wolf <kwolf@redhat.com>2018-11-19 12:51:40 +0100
commitd3e1a7eb4ceb9489d575c45c9518137dfbd1389d (patch)
tree29e6352dfbacfee2dc6892158ddf7f1ec9ad083f /block/qcow2.h
parent443ba6befa2f47243def9b190c930a8a4f59f888 (diff)
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>
Diffstat (limited to 'block/qcow2.h')
0 files changed, 0 insertions, 0 deletions