lkml.org 
[lkml]   [2004]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: delay in block_read_full_page()
Michael Mesnier <mmesnier@ece.cmu.edu> wrote:
>
> Hello,
>
> Please cc: me directly in your response.
>
> I'm running into some trouble with an installable file system I'm
> writing. In myfs_readpage() I simply return block_read_full_page() which
> subsequently calls myfs_get_block(). However, there's a delay before
> the I/O actually gets issued to the device. Running sync from the
> command line causes the I/O to get issued immediately, so the sync call
> (even it there aren't dirty buffers) also manages to schedule any
> outstanding read I/Os. How should my fs indicate to the vfs that these
> read I/Os need to be issued immediately after my_readpage() is called?

Normally we leave the I/O pending in the expectation that more readpage()
requests will occur. This allow us to merge things in the disk request
queues. We'll actually submit the I/O to the device if:

a) There's a lot of it pending or

b) There haven't been any more readpage() calls for a while or

c) Someone actually wants to wait on the I/O (say, via lock_page())

It is unusual that you want this I/O to kick off immediately. You will
probably find that blk_run_backing_dev() will do what you want.


That's all for a 2.6 kernel - you didn't specify. It it's a 2.4 kernel
then you'll need to use run_task_queue(&tq_disk) to flush the queued I/O
requests.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.112 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site