[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH for 3.1 v9] qcow2: Document some maximum size co
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH for 3.1 v9] qcow2: Document some maximum size constraints |
Date: |
Fri, 16 Nov 2018 16:55:21 +0100 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Am 15.11.2018 um 19:34 hat Eric Blake geschrieben:
> 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 <address@hidden>
>
> ---
> v9: Yet more wording tweaks, to call out the difference between
> inherent (L2 reserved bit) and implementation (qemu's 32M L1 and
> 8M refcount) limits.
>
> Designed to replace commit 1da4dc02 on Kevin's block branch.
Thanks, replaced the commit.
Kevin