My apologies for mixing the subject with what I was really trying to find
out, although all of the respondees addressed my actual concern. Cachefs
has nothing to do with my issue.
Fsflush is what forces data to disk from cache. It runs as pid 3 and
awakens every second to force this write. It is turned on be default
meaning the cache is on by default.
If this is not often enough there are 2 options that were presented to me:
forcedirectio and O_SYNC/D_SYNC/R_SYNC flags and/or fsync(). Forcedirectio
will work like a raw partition forcing (you guessed it) direct io to disk.
The other one I have given to the dba's to check on. Apparently most major
databases use this already for just my type of concern.
The reason for moving to fs from raw is one of ease of management and
recovery. Speed was not a major concern in this case (although everything
I've read says that ufs has improved much over the years and there is
little, if any, performance difference between the 2).
I would like to thank the following people for their information:
---------------------- Forwarded by Jeff Kennedy/NDS on 08/30/99 01:10 PM
"Jeff Kennedy" <email@example.com> on 08/25/99 09:27:08 AM
cc: (bcc: Jeff Kennedy/NDS)
I have a question from the dba side of the house and don't know the answer.
We are moving a sybase db to a new server. The old server used raw
partitions for the db and they want the new server to use fs.
The reason the old one used raw was for one reason only, possible fs cache
issues. Basically they were worried that, when a user entered a commit,
unless it was a raw partition, the data would instead be written to the fs
cache and then written to the db sometime later. Apparently, on a raw
partition the commit is immediate.
Now for the question, does the fs do this sort of thing by default or does
it require implementation?
Solaris 2.6 is the OS.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:25 CDT