[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v3 2/4] qcow2: Document some maximum size constr
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-block] [PATCH v3 2/4] qcow2: Document some maximum size constraints |
Date: |
Tue, 27 Feb 2018 12:47:02 +0100 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
Am 22.02.2018 um 16:59 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, and how choice of cluster size
> can influence some of the limits.
>
> While at it, notice that since we cannot map any virtual cluster
> to any address higher than 64 PB (56 bits) (due to the L1/L2 field
> encoding), it makes little sense to require the refcount table to
> access host offsets beyond that point. Mark the upper bits of
> the refcount table entries as reserved, with no ill effects, since
> it is unlikely that there are any existing images larger than 64PB
> in the first place, and thus all existing images already have those
> bits as 0.
>
> Signed-off-by: Eric Blake <address@hidden>
I think it would be good to mention the exact reason for the 56 bits in
the spec. Even this commit message is rather vague ('L1/L2 field
encoding'), so if at some point someone wonders, if we couldn't simply
extend the allowed range, they won't easily see that it's related to
compressed clusters.
Kevin
[Qemu-block] [PATCH v3 4/4] qcow2: Avoid memory over-allocation on compressed images, Eric Blake, 2018/02/22
[Qemu-block] [PATCH v3 3/4] qcow2: Don't allow overflow during cluster allocation, Eric Blake, 2018/02/22