Re: [PATCH, RFC] Use WRITE_SYNC in __block_write_full_page() if WBC_SYNC_ALL

[Theodore Tso <tytso@mit.edu>]

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@mit.edu> 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