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 - 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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:36 EST