Messages in this thread | | | Date | Mon, 4 Feb 2002 18:29:42 +0000 | From | Joel Becker <> | Subject | Re: O_DIRECT fails in some kernel and FS |
| |
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/
| |