Doubt regarding BIO handling

[Gaurav Mahajan]

Hello all,

Thanks for the information!!!



On Mon, Dec 27, 2010 at 2:37 PM, Prasad Joshi <prasadjoshi124 at gmail.com> wrote:
> On Mon, Dec 27, 2010 at 6:01 AM, Gaurav Mahajan
> <gauravmahajan2007 at gmail.com> 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 at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>

Thanks,
Gaurav.