qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] I have some questions in block , can anyone help me, th


From: Stefan Hajnoczi
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
User-agent: Mutt/1.5.21 (2010-09-15)

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



reply via email to

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