Hello all, Thanks for the information!!! On Mon, Dec 27, 2010 at 2:37 PM, Prasad Joshi <prasadjoshi124@xxxxxxxxx> wrote: > On Mon, Dec 27, 2010 at 6:01 AM, Gaurav Mahajan > <gauravmahajan2007@xxxxxxxxx> wrote: >> Hi all, >> >> I have a doubt regarding the handling of bios. >> >> Suppose I receive a bio at some layer, and I want to split it into >> multiple bios. There are layers below the one I am working on and the >> final I/O operations will be handled by those layers. So, basically , >> after some processing, I want to hand over the bio to the lower layer. >> Now, if I have split the original bio into multiple bios and submitted >> all the newly formed bios, I shall receive each such bio in the >> bio->bio_end_io function. >> >> Here is it necessary to merge these bios so that the original bio can >> be formed or is it ok to just split the original bio, receive the >> requested data in multiple bios and leave it at that ? >> > > IMHO, you still need to call bio->bio_end_io on the original BIO > structure. So instead of splitting the original BIO. I think, You > might want to keep the original BIO as it is. The smaller BIOs need to > point back to original BIO and once all of the smaller BIOs have been > serviced. You might want to call bio_end_io() on the original BIO. > I think the method of pointing back to original bio, you wrote here is about managing bi_idx fields of the split bios and keeping bio_vec array same for all. Can you please elaborate on this, if I'm wrong? Also I wanted to split one bvec into two bvecs. So I tried to split it using bvec's length and offset fields, but I am facing problem in merging these split bvecs in one. Or there is some other way I can do this? I am doubtful whether the pages are allocated for a bio when "read" is requested or when the actual data is read from disk (at the layer of I/O scheduler or device driver)? > Have a look if you can use bi_private field. > >> Looking forward to some help..... >> >> Regards, >> Gaurav >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies@xxxxxxxxxxxxxxxxx >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > Thanks, Gaurav. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
