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
