On Mon, Jan 05, 2009 at 10:47:13AM -0800, Andrew Morton wrote: > On Mon, 5 Jan 2009 09:47:40 -0500 Theodore Tso <tytso@xxxxxxx> wrote: > > > there will be times (i.e., when we are doing a checkpoint as > > opposed to a commit, or in a fsync-heavy workload), where we will end > > up getting blocked behind kjournald, so upping the I/O priority really > > does make sense. > > Not if it will cause kjournald writes to be prioritised ahead of any > reads, I suspect. Writes are rarely synchronous, but with reads, > there's almost always someone waiting. If there is an fsync() in progress, someone's waiting; ditto in a checkpoint situation, although arguably those are much rarer. However, I can easily see situations such as a mail server where having a slightly increased priority is a good thing. So long-term, I suspect the hueristic which makes sense is that in the case where there is an fsync() in progress, any writes which take place as a result of that fsync (which includes the journal records as well as ordered writes that are being forced out as a result of data=ordered and which block the fsync from returning), should get a hint which propagates down to the block layer that these writes *are* synchronous in that someone is waiting for them to complete. They shouldn't necessarily be prioritized ahead of other reads (unless they are readahead operations that couldn't be combined with reads that *are* synchronous that someone is waiting for completion), but they should be prioritized ahead of asynchronous writes. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
