From: Stefan Hajnoczi <stefanha@gmail.com>
To: Gaurab Basu <basugaurab88@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Qcow2 allocate and free cluster
Date: Fri, 5 Oct 2012 10:07:14 +0200 [thread overview]
Message-ID: <20121005080714.GB1399@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <CAPweRzpsWyeRYGpw-WV_SE3tA5RWimZs8Ya+G0Ujnp1rbiDUpA@mail.gmail.com>
On Fri, Sep 21, 2012 at 11:15:42AM +0530, Gaurab Basu wrote:
> My question is how the clusters are allocated. What I have understood, it
> maintains a free_cluster_index to manage which host clusters are free.
> In the function update_refcount(), if a cluster is freed it makes the
> free_cluster_index point to that cluster. (if cluster_index <
> free_cluster_index )
> For allocating, in the function alloc_clusters_noref(), it uses the
> free_cluster_index to search for free clusters.
>
> So, suppose I have 1000 clusters which are all allocated, then while
> freeing, the 2nd cluster gets freed, so the free_cluster_index points to
> 2nd cluster.
> Now, if want to allocate 5 contiguous clusters, i have to search all the
> way from 2 to 1000 before getting the 5 clusters.
> Am I right in interpreting the mechanism?. If so, isn't it very slow to
> search for all the clusters everytime.
free_cluster_index is just a "last freed cluster" index. The real allocation
map is the refcount data, which records whether each image file cluster is in
use or not.
The refcount data needs to be searched if free_cluster_index doesn't point to a
location with enough free space. Fancier data structures could be used to
track free space but this potential performance bottleneck is needs a benchmark
so that optimization can be done scientifically.
Do you have a case where finding free clusters is a bottleneck?
Stefan
prev parent reply other threads:[~2012-10-05 8:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-21 5:45 [Qemu-devel] Qcow2 allocate and free cluster Gaurab Basu
2012-10-05 8:07 ` Stefan Hajnoczi [this message]
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=20121005080714.GB1399@stefanha-thinkpad.redhat.com \
--to=stefanha@gmail.com \
--cc=basugaurab88@gmail.com \
--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).