lkml.org 
[lkml]   [2002]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:23    [W:0.100 / U:1.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site