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/