qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Alberto Garcia <berto@igalia.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Max Reitz <mreitz@redhat.com>, Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-2.12 v2] qcow2: Reset free_cluster_index when allocating a new refcount block
Date: Wed, 21 Mar 2018 14:52:38 +0100	[thread overview]
Message-ID: <20180321135238.GA3898@localhost.localdomain> (raw)
In-Reply-To: <20180321133852.3560-1-berto@igalia.com>

Am 21.03.2018 um 14:38 hat Alberto Garcia geschrieben:
> This can be reproduced easily:
> 
>      qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M
>      qemu-io -c 'write 0 124k' hd.qcow2
> 
> After this the image has 132608 bytes (256 clusters), and the refcount
> block is full. If we write 512 more bytes it should allocate two new
> clusters: the data cluster itself and a new refcount block.
> 
>      qemu-io -c 'write 124k 512' hd.qcow2
> 
> However the image has now three new clusters (259 in total), and the
> first one of them is empty (and unallocated):
> 
>      dd if=hd.qcow2 bs=512c skip=256 count=1 | hexdump -C
> 
> If we write larger amounts of data in the last step instead of the 512
> bytes used in this example we can create larger holes in the qcow2
> file.

So if I understand correctly, this is what we get:

0x20000: free
0x20200: refcount block
0x20400: data cluster
0x20600: potential next data cluster

> What this patch does is reset s->free_cluster_index to its previous
> value when alloc_refcount_block() returns -EAGAIN. This way the caller
> will try to allocate again the original clusters if they are still
> free.

This is an improvement, because now we should avoid the unused cluster:

0x20000: data cluster
0x20200: refcount block
0x20400: potential next data cluster

But now the data clusters are fragmented. Should we try to change the
logic so that already the refcount block allocation can make use of the
free space? That is:

0x20000: refcount block
0x20200: data cluster
0x20400: contiguous potential next data cluster

Kevin

  reply	other threads:[~2018-03-21 13:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 13:38 [Qemu-devel] [PATCH for-2.12 v2] qcow2: Reset free_cluster_index when allocating a new refcount block Alberto Garcia
2018-03-21 13:52 ` Kevin Wolf [this message]
2018-03-21 14:10   ` Alberto Garcia
2018-03-21 15:07     ` Kevin Wolf
2018-03-21 15:32       ` Alberto Garcia
2018-03-21 15:40         ` Kevin Wolf
2018-03-21 17:52 ` Kevin Wolf

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=20180321135238.GA3898@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=berto@igalia.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).