All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Maria Kustova" <maxa@catit.be>,
	qemu-devel@nongnu.org, "Benoît Canet" <benoit@irqsave.net>
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	[thread overview]
Message-ID: <20140523111850.GA5254@noname.redhat.com> (raw)
In-Reply-To: <1400751770-14594-1-git-send-email-stefanha@redhat.com>

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 <maxa@catit.be>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
>  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

  parent reply	other threads:[~2014-05-23 11:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22  9:42 [Qemu-devel] [PATCH] docs: clarify that qcow2 file size is not always a cluster multiple Stefan Hajnoczi
2014-05-22 16:52 ` Eric Blake
2014-05-23 11:18 ` Kevin Wolf [this message]
2014-05-26 11:57   ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140523111850.GA5254@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=benoit@irqsave.net \
    --cc=maxa@catit.be \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.