[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v3] specs/qcow2: Fix documentation of the compre

From: Eric Blake
Subject: Re: [Qemu-block] [PATCH v3] specs/qcow2: Fix documentation of the compressed cluster descriptor
Date: Wed, 21 Feb 2018 16:10:07 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 02/21/2018 08:08 AM, Alberto Garcia wrote:
This patch fixes several mistakes in the documentation of the
compressed cluster descriptor:

More things to consider, as followup patches:

Note that both the L1 table, and the standard L2 descriptors, have a cap on bit 55 as the maximum host offset (< 64PB). But for compressed clusters, our maximum depends on cluster_bits, as follows:

512 byte cluster: bit 61 forms 'number clusters', leaving bits 60-0 for computing the host offset. But even though this looks on the surface like you could allocate 2EB of compressed clusters, it does not play well with the rest of the L1/L2 system, so we should probably explicitly document that bits 60-56 MUST be 0, if they are assigned to the 'host offset field', making the maximum compressed cluster offset at 64PB.

2M cluster: bits 61-50 form 'number clusters', leaving bit 49 as the maximum bit in the host offset (< 512 TB). But we never validate that we don't overflow this value! I'm working on a patch.

Meanwhile, the refcount table currently allows all the way up to bit 63 to form an offset to a refcount block, although capping that at 55 the way L1/L2 are capped would be reasonable (it gets weird to state that your metadata must live below 64PB but that your data pointed to by the metadata can live beyond that point). So it may also be worth considering a spec patch that points out the 64PB maximum useful size, and maybe even a comment that the maximum size may be further constrained by the protocol layer (for example, ext4 has a 16TB cap on individual file size).

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]