6386 shutdown: (was something else - now sync and flushing)

[R.HUTCHISON]

>From article <940 at cetia4.UUCP>, by chris at cetia4.UUCP (Christian Bertin):
> In article <12044 at bloom-beacon.MIT.EDU>, jfc at athena.mit.edu (John F Carr) writes:
}   (talking about the 'update' daemon)
}>
}> It doesn't appear to place much load on a system to do this twice
}> per minute (perhaps 2 minutes CPU per day of runtime).
}> 
}>     --John Carr (jfc at athena.mit.edu)
} 
} 
} If you have a large buffer cache (1Mb on my system) and if you do a lot of
} compiles, or if you do anything that creates large temporary files, you can
} waste a LOT of time sync'ing files that should never have been written out
} to disk. The last time I tried to measure this, a 3 hour compile session went
} down to 2:40 after I changed the sync time from 30 seconds to 2 minutes.
} 
} At the very least, 'update' should take an optionnal argument to customize the
} sync intervals.
} 
} Chris
} -- 
} Chris Bertin	| -- CETIA -- 150, Av Marcelin Berthelot, Z.I. Toulon-Est
} +33(94)212005	| 83088 Toulon Cedex, France
} 		| inria!cetia!chris

In the OS environment (V/386) originally described, there is a process named
"bdflush" that does most of the work (but not all) of "sync" on
regular intervals (I believe every second, although that's tunable).
It does flush out dirty buffers but it doesn't force the writing of
dirty inodes like sync (update) does.  Adding occasional "sync"s
shouldn't impact the system too much because all it has to do is
flush a few blocks (perhaps) and any dirty inodes.  You should never
have more than one second's worth of dirty buffers not already queued
for writing.

I noticed above that you have a 1M buffer cache.  If you are using
V/386, how did you get it?  I have only been able to increase mine to
600K - I would like it bigger (I have sufficient memory and do a lot
of file I/O).  Does anyone know the technical reason for this
limitation (if this hasn't already been beaten to death before)?

Bob Hutchison
att!lzaz!hutch