Jan Wieck wrote:Bruce Momjian wrote: > I would be interested to know if you have the background write process > writing old dirty buffers to kernel buffers continually if the sync() > load is diminished. What this does is to push more dirty buffers into > the kernel cache in hopes the OS will write those buffers on its own > before the checkpoint does its write/sync work. This might allow us to > reduce sync() load while preventing the need for O_SYNC/fsync().
I tried that first. Linux 2.4 does not, as long as you don't tell it by reducing the dirty data block aging time with update(8). So you have to force it to utilize the write bandwidth in the meantime. For that you have to call sync() or fsync() on something.
Maybe O_SYNC is not as bad an option as it seems. In my patch, the checkpointer flushes the buffers in LRU order, meaning it flushes the least recently used ones first. This has the side effect that buffers returned for replacement (on a cache miss, when the backend needs to read the block) are most likely to be flushed/clean. So it reduces the write load of backends and thus the probability that a backend is ever blocked waiting on an O_SYNC'd write().
I will add some counters and gather some statistics how often the backend in comparision to the checkpointer calls write().
OK, new idea. How about if you write() the buffers, mark them as clean and unlock them, then issue fsync(). The advantage here is that we can
Not really new, I think in my first mail I wrote that I simplified this new mdfsyncrecent() function by calling sync() instead ... other than that the code I posted worked exactly that way.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
