linux-ext4 - Re: [PATCH, RFC] Use WRITE_SYNC in __block_write_full_page() if WBC_SYNC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 5 Jan 2009 14:35:17 -0500
From:	Theodore Tso <tytso@....edu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Jens Axboe <jens.axboe@...cle.com>, linux-ext4@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH, RFC] Use WRITE_SYNC in __block_write_full_page() if
	WBC_SYNC_ALL

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@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html