Messages in this thread | | | Date | Fri, 12 Jan 2007 16:17:38 -0500 (EST) | From | Linus Torvalds <> | Subject | Re: O_DIRECT question |
| |
On Sat, 13 Jan 2007, Michael Tokarev wrote: > > (No, really - this load isn't entirely synthetic. It's a typical database > workload - random I/O all over, on a large file. If it can, it combines > several I/Os into one, by requesting more than a single block at a time, > but overall it is random.)
My point is that you can get basically ALL THE SAME GOOD BEHAVIOUR without having all the BAD behaviour that O_DIRECT adds.
For example, just the requirement that O_DIRECT can never create a file mapping, and can never interact with ftruncate would actually make O_DIRECT a lot more palatable to me. Together with just the requirement that an O_DIRECT open would literally disallow any non-O_DIRECT accesses, and flush the page cache entirely, would make all the aliases go away.
At that point, O_DIRECT would be a way of saying "we're going to do uncached accesses to this pre-allocated file". Which is a half-way sensible thing to do.
But what O_DIRECT does right now is _not_ really sensible, and the O_DIRECT propeller-heads seem to have some problem even admitting that there _is_ a problem, because they don't care.
A lot of DB people seem to simply not care about security or anything else.anything else. I'm trying to tell you that quoting numbers is pointless, when simply the CORRECTNESS of O_DIRECT is very much in doubt.
I can calculate PI to a billion decimal places in my head in .1 seconds. If you don't care about the CORRECTNESS of the result, that is.
See? It's not about performance. It's about O_DIRECT being fundamentally broken as it behaves right now.
Linus - 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/
| |