Buffer flushing

[Paul de Bra]

In article <911 at sixhub.UUCP> davidsen at sixhub.UUCP (bill davidsen) writes:
>
>  Most flavors of SysV and some BSD systems have a process which does a
>sync from time to time, such as "update." When the kernel is configured
>to have a large number of buffers the result is a slowdown in
>performance for disk intensive tasks.
>
>  Many versions provide a tuning parameter which allows this to happen
>more or less often, but it still happens all at once. What I would like
>is a way to force or at least encourage the system to write dirty
>buffers out as a idle task, so that if the CPU is available and there
>are dirty buffers they are queued, but only at some faitly slow rate,
>perhaps 3-5% of the buffers per second.
>...

SysVr3.2 comes close to this, except that the kernel does not check whether
the system was idle. There are 2 parameters for buffer flushing:
BDFLUSHR and NAUTOUP
Every BDFLUSHR seconds the kernel looks for buffers that are dirty for
at least NAUTOUP seconds and writes those to disk. This means that
the buffers are not written "all at once", but at a rate similar to the
rate at which they were made dirty.

By increasing NAUTOUP one can delay the update process, at the risk of
losing more buffers on panic or power fail. My rule of thumb is to have
NAUTOUP be large enough for most short-time actions to finish before
NAUTOUP seconds have elapsed. (If most compiles take 30 seconds or less
you could set NAUTOUP to 30, and the temporary intermediate files will
never be actually written to disk since they are deleted before NAUTOUP
seconds pass).
Increasing BDFLUSHR improves overall system performance a little by
reducing the number of times the buffer pool has to be scanned, but it
means that probably more buffers will be written to disk all at once,
which may be undesirable for the person who asked the question.

Paul.
(debra at research.att.com)