qemu-devel
[Top][All Lists]
Advanced

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

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


From: Alberto Garcia
Subject: Re: [Qemu-devel] [PATCH v3] specs/qcow2: Fix documentation of the compressed cluster descriptor
Date: Thu, 22 Feb 2018 11:01:07 +0100
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Wed 21 Feb 2018 11:10:07 PM CET, Eric Blake 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.

Good catch!

> 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).

Sounds reasonable.

Berto



reply via email to

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