Messages in this thread | | | Date | Sun, 7 Nov 2004 02:45:45 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| |