Alan,
There's this issue of Oracle double buffering that is probably as
serious for performance as O_SYNC behavior. A very simple generic way
to implement a directFS and eliminate the double buffering for Oracle
for all the FS's for Oracle is to have a special version of bread() and
brelse() that would always force calls to ll_rw_block() for READ and
WRITE and would allow the user to pass their own buffer head if the
caller specifies O_SYNC. The problem with this approach, however, is
that filesystem meta-data may not get flushed right away since it would
still be in the buffer cache (which would need fsync() behavior), which
may be OK, since the requirement for commit operations assumes DATA will
get updated real time.
This approach would allow us to quickly implement a DirectFS interface
for O_SYNC for all the FS's that eliminated double buffering (since the
caller could provide the memory) and still allow file systems the
flexibility to customize their meta-data behavior so we don't do
something as heavy as fsync().
:-)
Respectfully Submitted,
Jeff
Alan Cox wrote:
>
> > So what's wrong with calling fsync() after write() then for Oracle --
> > this should work -- yes?
>
> If our fsync was efficient then yes. Its possibly a good argument for sorting
> out an inode->dirty buffer/page list. That would speed up fsync and make
> O_SYNC easy to fix
>
> -
> 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 : Tue May 23 2000 - 21:00:11 EST