Xref: utzoo comp.unix.wizards:17013 comp.sys.att:6790
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!indri!ames!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.unix.wizards,comp.sys.att
Subject: Re: 6386 shutdown: I CAN'T BELIEVE at&t was really this stupid!
Summary: what about bdflush?
Message-ID: <49@calcite.UUCP>
Date: 23 Jun 89 06:33:59 GMT
References: <483@oglvee.UUCP> <14401@bfmny0.UUCP> <12044@bloom-beacon.MIT.EDU> <940@cetia4.UUCP>
Organization: Rhyolite Software, Mountain View, CA
Lines: 17


The continuing discussion of an old fashioned update(1m) deamon for SVR3 is
puzzling.  SVR3 has the kernel process which ps lists 'bdflush'.  It does
better write-behind than a periodic, complete buffer flush flood like the
update deamon.  In at least some versions, one can tune bdflush's aging
parameters.

Separately, some file systems are careful to invalidate buffers containing
data for unlinked files when the in-core inode reference count goes to 0.
Bdflush may never have a chance to write such disk blocks.  That strategy
can have a measurable effect on the speed of things like C compilers.

It is irritating as well as unusual to have to say something nice about
System V, but truth is truth.

Vernon Schryver
vjs@calcite.uucp