qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] docs: clarify that qcow2 file size is not alway


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] docs: clarify that qcow2 file size is not always a cluster multiple
Date: Fri, 23 May 2014 13:18:50 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 22.05.2014 um 11:42 hat Stefan Hajnoczi geschrieben:
> Normally one would expect that qcow2 image file lengths are multiples of
> the cluster size.  This is not true in all cases and the spec should
> document this so implementers remember to accept such files.
> 
> $ qemu-img create -f qcow2 foo.qcow2 2G
> Formatting 'foo.qcow2', fmt=qcow2 size=2147483648 encryption=off 
> cluster_size=65536 lazy_refcounts=off
> $ ls -l foo.qcow2
> -rw-r--r-- 1 stefanha stefanha 197120 May 22 11:40 foo.qcow2
> $ bc -q
> 3 * (64 * 1024) + 512
> 197120
> 
> The extra sector are the 4 L1 table entries that a 2 GB disk with 64 KB
> cluster size needs.  The rest of the L1 table is omitted from the file
> but allocation will continue at the next cluster boundary.
> 
> Reported-by: Maria Kustova <address@hidden>
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
>  docs/specs/qcow2.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
> index f19536a..a46ee57 100644
> --- a/docs/specs/qcow2.txt
> +++ b/docs/specs/qcow2.txt
> @@ -4,6 +4,10 @@ A qcow2 image file is organized in units of constant size, 
> which are called
>  (host) clusters. A cluster is the unit in which all allocations are done,
>  both for actual guest data and for image metadata.
>  
> +If the end of the image file is not on a cluster boundary, the missing data 
> is
> +treated as zeroes.  This layout can occur when an L1 table or refcount table 
> is
> +the last thing in the file and not all entries in the table are used.
> +
>  Likewise, the virtual disk as seen by the guest is divided into (guest)
>  clusters of the same size.

Why don't we specify this for _any_ data after EOF, as we discussed on
IRC, instead of just for a partial last cluster?

If we restrict it to the last cluster, specifying the data as zero
doesn't make a whole lot of sense because then the data there wouldn't
be supposed to be interpreted anyway.

Kevin



reply via email to

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