On Thu, Apr 13, 2000 at 10:38:50PM +0200, Manuel Bouyer wrote:
> > 
> > There's another issue with the way Linux seems to handle the buffer
> > cache.  It seems to like to delay writes until the last possible moment,
> > which makes the machine seem to run really fast until it needs to flush
> > everything to disk at which point the machine siezes up.
> 
> NetBSD used to behave the same way with the traditionnal update(8) and a large
> buffer cache (although this was sync(2) which freese the I/O, I don't know
> for linux). Now that with soft updates we got the ioflush thread, this
> doesn't happen (unless someone type 'sync' maybe, I didn't try :)

Actually, that's not quite right.  We have the old "sprite" interval
flush policy: we flush all buffers -- pages, eventually? -- for a file
when the oldest buffer in that file hits 30 seconds.

This is *not* the same as the policy generally considered to be correct
since the Mogul paper: flush each buffer when it hits 30 seconds of age.

There are some very common cases which are pathological for the algorithm
we have in that its performance degrades to that of the old "flush all
buffers every 30 seconds of wall-clock time" method.  For example, if
you have a system that does most of its I/O to a single file... you lose.

On the other hand, the "right" way is pretty hard to do with UBC.  What
do you do, attach a timeval to every page?