[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: |
Max Reitz |
Subject: |
Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature |
Date: |
Thu, 20 Feb 2020 16:54:09 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
On 22.12.19 12:36, Alberto Garcia wrote:
> Subcluster allocation in qcow2 is implemented by extending the
> existing L2 table entries and adding additional information to
> indicate the allocation status of each subcluster.
>
> This patch documents the changes to the qcow2 format and how they
> affect the calculation of the L2 cache size.
>
> Signed-off-by: Alberto Garcia <address@hidden>
> ---
> docs/interop/qcow2.txt | 68 ++++++++++++++++++++++++++++++++++++++++--
> docs/qcow2-cache.txt | 19 +++++++++++-
> 2 files changed, 83 insertions(+), 4 deletions(-)
>
> diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
> index af5711e533..d34261f955 100644
> --- a/docs/interop/qcow2.txt
> +++ b/docs/interop/qcow2.txt
> @@ -39,6 +39,9 @@ The first cluster of a qcow2 image contains the file header:
> as the maximum cluster size and won't be able to open
> images
> with larger cluster sizes.
>
> + Note: if the image has Extended L2 Entries then
> cluster_bits
> + must be at least 14 (i.e. 16384 byte clusters).
> +
> 24 - 31: size
> Virtual disk size in bytes.
>
> @@ -109,7 +112,12 @@ in the description of a field.
> An External Data File Name header extension
> may
> be present if this bit is set.
>
> - Bits 3-63: Reserved (set to 0)
> + Bit 3: Extended L2 Entries. If this bit is set then
I suppose bit 4 now. (Compression is bit 3.)
[...]
> +Subcluster Allocation Bitmap (for standard clusters):
> +
> + Bit 0 - 31: Allocation status (one bit per subcluster)
> +
> + 1: the subcluster is allocated. In this case the
> + host cluster offset field must contain a valid
> + offset.
> + 0: the subcluster is not allocated. In this case
> + read requests shall go to the backing file or
> + return zeros if there is no backing file data.
> +
> + Bits are assigned starting from the most significant one.
> + (i.e. bit x is used for subcluster 31 - x)
I still prefer it the other way round, both personally (e.g. it’s the C
ordering), and because other places in qcow2 use LSb for bit ordering
(the refcount order).
I don’t see ease of debugging as a particularly good reason; but then
again, I didn’t have to debug this feature yet (as opposed to you).
But since I’m used to counting bits from the right (because this is how
it’s done basically everywhere), I can’t imagine I would find it more
difficult than counting them from the left.
Max
> + 32 - 63 Subcluster reads as zeros (one bit per subcluster)
> +
> + 1: the subcluster reads as zeros. In this case the
> + allocation status bit must be unset. The host
> + cluster offset field may or may not be set.
> + 0: no effect.
> +
> + Bits are assigned starting from the most significant one.
> + (i.e. bit x is used for subcluster 63 - x)
signature.asc
Description: OpenPGP digital signature