Van,
Thanks for calling me back to discuss this today. What's up here is a
performance issue on Oracle regarding write through (Oracle will always
need the O_SYNC flag to ensure that a write is committed and data is not
cached -- a lot like the directFS in NetWare). What would be helpful
for Alan Cox and folks to understand performance relative behavior is
for you to explain how the Oracle cache works relative to direct I/O and
what expected impacts and performance issues should be considered
relative to our implementation of O_SYNC in Linux.
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.
Please advise.
Jeff
"Jeff V. Merkey" wrote:
>
> Alan,
>
> I ported the SMP Oracle to NetWare in 1994, and from what I've saw of
> their internal architecture (which is like most databases) they always
> seem to assume they have a more direct interface to the file systems
> (i.e. on NetWare, Oracle uses the DirectFS interface which by-passed the
> cache completely). Oracle also provided it's own caching above the OS
> for remote SQL users. When they called DirectFS, it was always with an
> "O_SYNC" semantic, which I think is the spirit here. If the database is
> using fsync() all the time, one would assume it's because they are doing
> a commit operation (or updating a rollback segment) and expect a
> write-through to occur.
>
> I think this is not as critical as you think for Databases unless
> there's some database implementation out there that isn't optimized as
> well as Oracle, in which case, it should not be doing O_SYNC calls all
> the time, just on commits or rollback updates.
>
> :-)
>
> I think this is probably OK.
>
> Jeff
>
> Alan Cox wrote:
> >
> > > Well, maybe O_SYNC is so rare that slowdown might be acceptable.
> >
> > it isnt. Its a performance critical path for databases.
> >
> > -
> > 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/
-
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:26 EST