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