Block device driver question

[neha naik]

Hi Pranay,
Your answers assume that there is always a filesystem above the block
device driver which is not necessarily condition.

Regards,
Neha
 On Nov 2, 2013 8:58 AM, "Pranay Srivastava" <pranjas at gmail.com> wrote:

>
> On 01-Nov-2013 10:57 PM, "neha naik" <nehanaik27 at gmail.com> wrote:
> >
> > Hi,
> >   I am writing a block device driver and i am using the
> > 'blq_queue_make_request' call while registering my block device
> > driver.
> >   Now as far as i understand this will bypass the linux kernel queue
> > for each block device driver (bypassing the elevator algorithm etc).
> > However, i am still not very clear about exactly how i get a request.
> >
> >  1.  Consider i am doing a dd on the block device directly :
> >   Will it bypass the buffer cache(/page cache) or will it use it.
>
> Page cache use is for file system. Block driver has got nothing to do with
> it. So lets keep these separate.
>
> Bios don't care which page you give them all it needs is a page in bvec.
> The file system would wait on that page to be uptodate which might be done
> in bio_end_io if i/o was good.
>
> In case of buffer heads the same thing. Submit_bh would create a bio for
> that bh so really same stuff.
>
> > Example if i register my block device with set_blocksize() as 512. And
> > i do a dd of 512 bytes will i get a read because it passes through the
> > buffer cache and since the minimum page size is 4096 it has to read
> > the page first and then pass it to me.
>
> If you are writing why it would read the page? Reads would initiate write
> outs i think. Take a look at generic_file_aio_write.
>
> >     I am still unclear about the 'page' in the bvec. What does that
> > refer to? Is it a page from the page cache or a user buffer (DMA).
>
> Whatever filesystem gave it. If it uses the generic functions that should
> come from page cache but again it depends on how filesystem created bio.
>
> So for block driver you need to know if the page you are given in bvec is
> something you can use or you need to check and take measures to
> successfully do i/o.
>
> >
> >
> > 2. Another thing i am not clear about is a queue. When i register my
> > driver, the 'make_request' function gets called whenever there is an
> > io. Now in my device driver, i have some more logic about  writing
> > this io i.e some time may be spent in the device driver for each io.
> > In such a case, if i get two ios on the same block one after the other
> > (say one is writing 'a' and the other is writing 'b') then isn't it
> > possible that i may end up passing 'b' followed by 'a' to the layer
> > below me (changing the order because thread 'a' took more time than
> > thread 'b').
> Then in that case should i be using a queue in my layer -
> > put the ios in the queue whenever i get a call to 'make_request'.
> > Another thread keeps pulling the ios from the queue and processing
> > them and passing it to the layer below.
> >
> You mean layer above right? that is the filesystem correct? But if thats
> the case then wouldn't your second request be blocked until the page was
> unlocked by file system which would happen i think after your driver was
> done with i/o. Thats because you won't mark the request as complete so i
> guess threads would wait_on_page to be unlocked.
>
> If however your driver "lies" about completing requests then yeah you need
> to take appropriate measure.
>
> >
> > Regards,
> > Neha
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>         --P.K.S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20131102/20d4ce59/attachment.html