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

[Xen-devel] Try to understand the detail process of reading a block in domU ?


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Zhang Shukun <bitzsk@xxxxxxxxx>
  • Date: Sat, 6 Jun 2009 12:05:02 +0800
  • Delivery-date: Fri, 05 Jun 2009 21:05:51 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=h5CQ2UR3pQmFQ0pni1JxSn3T0TX5ggegZ/L8ABmlDednnT40A8OfkXD4YWKP9qw4zD 5sqiFxgXNVW0BIoH4eTI2d2PXAv669iPe6rxinMdrrLFrbNFAQBYzUfbqqczi1rxkFoI v+fhhdRUJyxSO+ZrRIfMKuuAE3yqDURZhat/8=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

HI,

I try to understand the detail process of read a block in domU , but meet some problem, confused me.

first, i change   funcntion void do_blkif_request(request_queue_t *rq), from

         DPRINTK("do_blk_req %p: cmd %p, sec %llx, "
            "(%u/%li) buffer:%p [%s]\n",
            req, req->cmd, (long long)req->sector,
            req->current_nr_sectors,
            req->nr_sectors, req->buffer,
            rq_data_dir(req) ? "write" : "read");
to

  printk("do_blk_req %p: cmd %p, sec %llx, "
            "(%u/%li) buffer:%p [%s]\n",
            req, req->cmd, (long long)req->sector,
            req->current_nr_sectors,
            req->nr_sectors, req->buffer,
            rq_data_dir(req) ? "write" : "read");
int order to see the message. when domU read blocks.

when boot up domU , some message displayed as follow:


do_blk_req cf9d1d3c: cmd cf9d1db8, sec 6d032, (2/2) buffer:cfae5000 [read]
do_blk_req cf9d1d3c: cmd cf9d1db8, sec 6c2d2, (2/2) buffer:d07b3400 [read]
do_blk_req cf9d1d3c: cmd cf9d1db8, sec 6d034, (2/2) buffer:cfae6000 [read]
do_blk_req cf9d1de8: cmd cf9d1e64, sec 6df0e, (2/2) buffer:cfae6400 [read]
do_blk_req cf9d1f40: cmd cf9d1fbc, sec 6df10, (2/2) buffer:cfae6800 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 71bec, (2/2) buffer:cfae6c00 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 71c54, (2/2) buffer:cfae7000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 6c2d0, (2/2) buffer:d07b3000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 71ca6, (8/26) buffer:cfae8000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 71cc0, (2/2) buffer:cfafa000 [read]
do_blk_req cf9d1f40: cmd cf9d1fbc, sec 6c248, (2/2) buffer:cfaed000 [read]
do_blk_req cf9d1f40: cmd cf9d1fbc, sec 6e754, (8/10) buffer:cfafb000 [read]
do_blk_req cf9d1f40: cmd cf9d1fbc, sec 71c92, (6/6) buffer:cfafd000 [read]
do_blk_req cf9d1f40: cmd cf9d1fbc, sec 6c2ce, (2/2) buffer:cfb1ec00 [read]
do_blk_req cf9d1f40: cmd cf9d1fbc, sec 71a0e, (2/2) buffer:cfafe000 [read]
do_blk_req cf9d1f40: cmd cf9d1fbc, sec 4758e, (8/64) buffer:cfaff000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 475ce, (8/72) buffer:cfb43000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 50016, (2/2) buffer:d0389c00 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 528d0, (2/2) buffer:cfb4c000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 642d6, (2/2) buffer:d07adc00 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 66518, (2/2) buffer:cfb4d000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 680ce, (2/2) buffer:cf416c00 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 6ad2c, (2/2) buffer:cfb4e000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 7007e, (2/2) buffer:cf418c00 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 73894, (2/2) buffer:cfb4f000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 70080, (2/2) buffer:cf419000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 73896, (8/26) buffer:cfb50000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 738b0, (8/34) buffer:d0763000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 84010, (2/2) buffer:cf421000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 862cc, (2/2) buffer:d0776000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 84016, (2/2) buffer:cf421c00 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 8635e, (8/18) buffer:d0777000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 86388, (6/6) buffer:cf426000 [read]
do_blk_req cf9d1be4: cmd cf9d1c60, sec 6ad34, (2/2) buffer:cf427000 [read]

i don't know what req refers to , is req mean a request tag?, and req-cmd is the same mean to req?

such as the same cf9d1be4  and same cf9d1c60 above?

i guess nr_sectors == current_nr_sectors + next current_nr_sectors + next current_nr_sectors + ...

such a the yellow backgroud lines above . i think 72 equal to

8+2+2+2+2+2+2+2+2+2+8+8+2+2+2+8+6+2 == 64 , but it's not true. can you tell me why? and how to compute or get the exact num of secters when a read or write request happens.

i have see the source code segment in the request struct :

    sector_t sector;        /* next sector to submit */
    unsigned long nr_sectors;    /* no. of sectors left to submit */
    /* no. of sectors left to submit in the current segment */
    unsigned int current_nr_sectors;
    char *buffer;
    unsigned char cmd[BLK_MAX_CDB];

but still not very clear about the comment above.

Thanks very much !



--
Regards,
Sucan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.