Re: O_DIRECT fails in some kernel and FS

[Joel Becker <jlbec@evilplan.org>]

On Mon, Feb 04, 2002 at 03:46:20PM +0000, Alan Cox wrote:
> > If an application is multithreaded and is doing mmap and direct I/O
> > from different threads without doing its own synchronization, then it
> > is broken, there is no ordering guarantee provided by the kernel as
> > to what happens first.
> 
> Providing we don't allow asynchronous I/O with O_DIRECT once asynchronous
> I/O is merged.

	Oh, but async + O_DIRECT is a good thing.  The fundamental
ordering comes down at the block layer.  Things are synchronous there.
An application using async I/O knows that ordering is not guaranteed.
Applications using O_DIRECT know they are skipping the buffer cache.
"Caveat emptor" and "Don't do that then" apply to stupid applications.
	The big issues I see are O_DIRECT alignment size (see my patch
to allow hardsectsize alignment on O_DIRECT ops) and whether or not to
synchronize with the caches upon O_DIRECT write.  Keeping the
page/buffer caches in sync with O_DIRECT writes is a bit of work,
especially with writes smaller than sb_blocksize.  You can either do
that work, or you can say that applications and people using O_DIRECT
should know the caches might be inconsistent.  Large O_DIRECT users,
such as databases, already know this.  They are happily ignorant of
cache inconsistencies.  All they care about is hardsectsize O_DIRECT
operations.

Joel

-- 

Life's Little Instruction Book #267

	"Lie on your back and look at the stars."

			http://www.jlbec.org/
			jlbec@evilplan.org