From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
To: Zhi Hui Li <zhihuili@linux.vnet.ibm.com>
Cc: QEMU-devel <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] I have some questions in block , can anyone help me, thank you!
Date: Mon, 14 Nov 2011 10:00:22 +0000 [thread overview]
Message-ID: <20111114100022.GA25870@stefanha-thinkpad.localdomain> (raw)
In-Reply-To: <4EC0AB7D.2020807@linux.vnet.ibm.com>
On Mon, Nov 14, 2011 at 01:47:41PM +0800, Zhi Hui Li wrote:
> 1) In qcow2.c, in function: qcow2_co_readv
> In qcow2.h, in struct BDRVQcowState
> I want to know the relations between sector_num in function
> qcow2_co_readv and cluster_sectors in struct BDRVQcowState ?
sector_num is the starting offset of the I/O request. For example,
sector_num=10 means that the read begins at 10 * 512 = 5120 bytes.
cluster_sectors is the number of sectors in a qcow2 cluster. (The qcow2
format manages space in "clusters" instead of sectors. They are
typically many sectors large, e.g. 128.)
> 2) In qcow2.c, in function; qcow2_co_writev
> at line 547:
>
> index_in_cluster = sector_num & (s->cluster_sectors - 1);
> How to understand it ?
cluster_sectors is a power of 2, e.g. 1024, 2048, 4096, and so on. So
this expression is the same as:
index_in_cluster = sector_num % cluster_sectors
It calculates the offset from the start of the cluster. For example:
sector_num = 130
cluster_sectors = 128
cluster = sector_num / cluster_sectors = 1
index_in_cluster = sector_num % cluster_sectors = 2
We can get back to the original sector_num value like this:
sector_num = cluster * cluster_sectors + index_in_cluster
= 1 * 128 + 2
= 130
So this is about managing space in "clusters". It's similar to how
memory is managed in pages instead of bytes by the memory management
unit.
> 3) In qcow2.c, in the function : qcow2_co_readv and qcow2_co_writev
> I want to know the least unit that it was read by the function.
> for example:
> BDRVQcowState s;
> Is s->cluster_size or 512 ?
The block layer minimum I/O size is BDRV_SECTOR_SIZE. For convenience
there is the bdrv_pread()/bdrv_pwrite() interface which allows
byte-granularity access but uses bounce buffers underneath.
s->cluster_size is the number of bytes per cluster. A cluster is
typically 64 KB but the value can be set in the image file. Qcow2
internally manages space in cluster but the I/O granularity is
BDRV_SECTOR_SIZE (512).
Stefan
next prev parent reply other threads:[~2011-11-14 10:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-07 7:46 [Qemu-devel] backing_file Path Zhi Hui Li
2011-11-07 9:17 ` Kevin Wolf
2011-11-07 15:03 ` Markus Armbruster
[not found] ` <4EB89ED1.90307@linux.vnet.ibm.com>
[not found] ` <m3bosnnlsp.fsf@blackfin.pond.sub.org>
2011-11-14 5:47 ` [Qemu-devel] I have some questions in block , can anyone help me, thank you! Zhi Hui Li
2011-11-14 10:00 ` Stefan Hajnoczi [this message]
2011-11-15 6:56 ` Zhi Hui Li
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=20111114100022.GA25870@stefanha-thinkpad.localdomain \
--to=stefanha@linux.vnet.ibm.com \
--cc=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=zhihuili@linux.vnet.ibm.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 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).