Van,
For O_SYNC writes, I am assuming you will be using you the cache in
Oracle, and that the O_SYNC case will be used flushing commits. What
frequecy of writes vs. reads do you normally exhibit, and what
percentage of writes will use the O_SYNC semantic. In my earlier
dialogue with Alan, the idea came up to call fsync() (which flushes the
cache) after any calls to write() with O_SYNC set in the file handle. I
think it would be nice to provide a something less coarse than:
write();
fsync();
Saying performance is critical is cool, but what would you consider
would be the best semantic to provide this behavior in a performant
manner that would allow Oracle to get best case performance?
Jeff
Van Okamura wrote:
>
> "Jeff V. Merkey" wrote:
> >
> > At present, we call fsync() (which flushes dirty pages from cache) after
> > a call to write() with an O_SYNC flag set (in essense creating a
> > behavior like direct FS where data is not cached and the database can
> > write-through the buffer cache. There is a belief that Oracle will
> > really suck wind with the current implementation.
> >
> Oracle expects that block written will hit the disk before the call
> returns. In a very busy system, Oracle could be writing most of the
> time. In this case, O_SYNC performance will be critical. DirectFS was
> good in that there was no double-buffering going on.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:27 EST