[Qemu-devel] backing_file Path

[Qemu-devel] backing_file Path

[Zhi Hui Li]

when I trace the code of qemu-img.c， I found in the image file, the 
backing_file use the relative path, I think Maybe it has some problems.

for example:

1: qemu-img create -o backing_file=../xxxx aa.img 5G

2: qemu-system-x86_64   aa.img

if you change aa.img's the path, the exec is wrong,it can't find the 
backing_file path, because the backing_file use the relative path,
Could we change the relative path to the absolute path?

Re: [Qemu-devel] backing_file Path

[Kevin Wolf]

Am 07.11.2011 08:46, schrieb Zhi Hui Li:
> 
> when I trace the code of qemu-img.c， I found in the image file, the 
> backing_file use the relative path, I think Maybe it has some problems.
> 
> for example:
> 
> 1: qemu-img create -o backing_file=../xxxx aa.img 5G
> 
> 2: qemu-system-x86_64   aa.img
> 
> if you change aa.img's the path, the exec is wrong,it can't find the 
> backing_file path, because the backing_file use the relative path,
> Could we change the relative path to the absolute path?

No, we can't. That would break compatibility of qemu-img create with
older versions. Relative paths have well-defined semantics, they are
relative to the image file.

Kevin

Re: [Qemu-devel] backing_file Path

[Markus Armbruster]

Zhi Hui Li <zhihuili@linux.vnet.ibm.com> writes:

> when I trace the code of qemu-img.c， I found in the image file, the
> backing_file use the relative path, I think Maybe it has some
> problems.
>
> for example:
>
> 1: qemu-img create -o backing_file=../xxxx aa.img 5G
>
> 2: qemu-system-x86_64   aa.img
>
> if you change aa.img's the path, the exec is wrong,it can't find the
> backing_file path, because the backing_file use the relative path,
> Could we change the relative path to the absolute path?

qemu-img stores exactly the path the user asks it to store.  That's a
feature.  It lets the user can pick what kinds of moves break his COW:

1. COW refers to its backing image with a relative path.  Moving both
together works.  Moving just one of them breaks.

2. COW refers to its backing image with an absolute path.  Moving just
the COW works.  Anything else breaks.

[Qemu-devel] I have some questions in block , can anyone help me, thank you!

[Zhi Hui Li]

questions:

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 ?



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 ?


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 ?



Thank you very much !

Best regards!

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

[Stefan Hajnoczi]

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

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

[Zhi Hui Li]

On 2011年11月14日 18:00, Stefan Hajnoczi wrote:
> 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
>
>


Thank you very much!