!!!!!help!I wouldn't be able to meet the deadline!(qcow format image file read operation in qemu-img-xen)[updated]

!!!!!help!I wouldn't be able to meet the deadline!(qcow format image file read operation in qemu-img-xen)[updated]

[hxkhust]

[-- Attachment #1.1: Type: text/plain, Size: 2344 bytes --]

Hi,guys,
During a HVM's running which take a qcow format image file as its own virtual disk, the qcow image file will be always read.In the situation that its qcow format image is based on a raw format image,  if nesethe backingfile ,just that raw format image file,would be read .my purpose is to cache the data that is read from the backingfile when the hvm is running .
Now what I concern is the following (which is in the /xen-4.1.2/tools/ioemu-qemu-xen/block-qcow.c) :
static void qcow_aio_read_cb(void *opaque, int ret)
{
........
if (!acb->cluster_offset) {
        if (bs->backing_hd) {
            /* read from the base image */
            acb->hd_aiocb = bdrv_aio_read(bs->backing_hd,                           //*************
                acb->sector_num, acb->buf, acb->n, qcow_aio_read_cb, acb);   //**************
//I read what the acb->buf points to, but find the reading operation is not finished. 
            if (acb->hd_aiocb == NULL)
                goto fail;
        } else {
            /* Note: in this case, no need to wait */
            memset(acb->buf, 0, 512 * acb->n);
            goto redo;
        }
    } else if (acb->cluster_offset & QCOW_OFLAG_COMPRESSED) {
        /* add AIO support for compressed blocks ? */
        if (decompress_cluster(s, acb->cluster_offset) < 0)
            goto fail;
        memcpy(acb->buf,
               s->cluster_cache + index_in_cluster * 512, 512 * acb->n);
        goto redo;
 .........
//********************************************************************************************8
when the statement:
acb->hd_aiocb = bdrv_aio_read(bs->backing_hd,
                acb->sector_num, acb->buf, acb->n, qcow_aio_read_cb, acb);n
has been completed, the content which the acb->buf points to has not been prepared.This is a asynchronous read operation.Who could tell me the principle or process about this  asynchronous read operation about these codes? if you describe it using the codes in xen,that will be so kind of you.I need to know when  the data has been copied to the memory which the acb->buf points to, and this problem is important to me.as the title mentioned ,I have to solve it as soon as possible.Or could you tell me how to cache the data which is read from the backingfile when a qcow image is regarded as a virtual disk in a running  HVM?


A newbie






[-- Attachment #1.2: Type: text/html, Size: 4044 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: !!!!!help!I wouldn't be able to meet the deadline!(qcow format image file read operation in qemu-img-xen)[updated]

[Mats Petersson]

On 19/12/12 15:23, hxkhust wrote:
> Or could you tell me how to cache the data which is read from the
> backingfile when a qcow image is regarded as a virtual disk in a
> running HVM?
I take it the above single question is the effect of my previous reply?
Why did you have to "hide" that little extra question in the whole
previous e-mail?

Sorry, don't know the answer to your question [I'm guessing, in general,
that the Dom0 will do that for you, subject to available space], just
pointing out that there is a minor difference between your previous and
current mail.

By caching, do you mean "load the entire file into RAM", or "if a read
is requested for the same piece of 'disk' multiple times, I want the
previous result to be stored and returned".

--
Mats

Re: !!!!!help!I wouldn't be able to meet the deadline!(qcow format image file read operation in qemu-img-xen)[updated]

[hxkhust]

[-- Attachment #1.1: Type: text/plain, Size: 1608 bytes --]

>Date: Wed, 19 Dec 2012 15:32:41 +0000
>From: Mats Petersson <mats.petersson@citrix.com>
>To: <xen-devel@lists.xen.org>
>Subject: Re: [Xen-devel] !!!!!help!I wouldn't be able to meet the
>	deadline!(qcow format image file read operation in
>	qemu-img-xen)[updated]
>Message-ID: <50D1DE19.1080709@citrix.com>
>Content-Type: text/plain; charset="GB2312"
>
>On 19/12/12 15:23, hxkhust wrote:
>> Or could you tell me how to cache the data which is read from the
>> backingfile when a qcow image is regarded as a virtual disk in a
>> running HVM?
>I take it the above single question is the effect of my previous reply?
>Why did you have to "hide" that little extra question in the whole
>previous e-mail?
>......yse,that is.Because previously what point out is a detail question, the reader may be convenient to answear and at least input less words to me, I guess.And in this way I can get the one that is more maneuverable.
>Sorry, don't know the answer to your question [I'm guessing, in general,
>that the Dom0 will do that for you, subject to available space], just
>pointing out that there is a minor difference between your previous and
>current mail.
>yean,the difference is minor.I have no time and I'm worry about the problem.I have seen that a lot of questions have more that one Re:XXX mails(mails to answer the question),How could they do that?  
>By caching, do you mean "load the entire file into RAM", or "if a read
>is requested for the same piece of 'disk' multiple times, I want the
>previous result to be stored and returned".
>I mean the latter one.Could you give me some proposal?
>--
>Mats

[-- Attachment #1.2: Type: text/html, Size: 2848 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: !!!!!help!I wouldn't be able to meet the deadline!(qcow format image file read operation in qemu-img-xen)[updated]

[Mats Petersson]

On 19/12/12 16:04, hxkhust wrote:
> >Date: Wed, 19 Dec 2012 15:32:41 +0000
> >From: Mats Petersson <mats.petersson@citrix.com>
> >To: <xen-devel@lists.xen.org>
> >Subject: Re: [Xen-devel] !!!!!help!I wouldn't be able to meet the
> >	deadline!(qcow format image file read operation in
> >	qemu-img-xen)[updated]
> >Message-ID: <50D1DE19.1080709@citrix.com>
> >Content-Type: text/plain; charset="GB2312"
> >
> >On 19/12/12 15:23, hxkhust wrote:
> >> Or could you tell me how to cache the data which is read from the
> >> backingfile when a qcow image is regarded as a virtual disk in a
> >> running HVM?
> >I take it the above single question is the effect of my previous reply?
> >Why did you have to "hide" that little extra question in the whole
> >previous e-mail?
> >
> ......yse,that is.
> Because previously what point out is a detail question, the reader may be convenient to answear and at least input less words to me, I guess.
You are, I suppose, aware that most members of this list hasn't even
replied to your original email, and most probably thought your re-send
was simply another copy of the same mail - given that there have been
about 100 mails to the list since, it's not inconceivable.

I very nearly missed the tiny difference between your first, second and
third posting.

> And in this way I can get the one that is more maneuverable.
> >Sorry, don't know the answer to your question [I'm guessing, in general,
> >that the Dom0 will do that for you, subject to available space], just
> >pointing out that there is a minor difference between your previous and
> >current mail.
> >
> yean,the difference is minor.I have no time and I'm worry about the problem.
> I have seen that a lot of questions have more that one Re:XXX mails(mails to answer the question),How could they do that?
Not sure what you are trying to say here. It is your task to make it as
easy as possible for us to help you. Please read the links I sent
earlier. It is REALLY going to help you get better help to understand
that if you "ask smart questions" you get good answers. Included in that
is "do not same the same email several times whilst ignoring replies
already given".
>   
> >By caching, do you mean "load the entire file into RAM", or "if a read
> >is requested for the same piece of 'disk' multiple times, I want the
> >previous result to be stored and returned".
> >
> I mean the latter one.Could you give me some proposal?
Keep some sort of memory structure that records the previously read
data, along with "where the data came from" [beware that this needs to
be updated/cleared if there is a write]. If you can find a read for the
location on "disk" that you have cached, then you can pretty much return
immediately.

Exactly what other problems you run into, I'm not sure - as I said
earlier, I'm not overly familiar with this code.

--
Mats
> >--
> >Mats
>
>