Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!hao!boulder!forys From: forys@sigi.Colorado.EDU (Jeff Forys) Newsgroups: news.config Subject: Re: (*Hiccup*) pyramid overflows /usr/spool Message-ID: <1650@sigi.Colorado.EDU> Date: Mon, 27-Jul-87 12:43:38 EDT Article-I.D.: sigi.1650 Posted: Mon Jul 27 12:43:38 1987 Date-Received: Tue, 28-Jul-87 03:34:59 EDT References: <3834@pyramid.pyramid.com> <2523@hoptoad.uucp> Reply-To: forys@boulder.Colorado.EDU (Jeff Forys) Distribution: world Organization: University of Colorado, Boulder Lines: 23 Summary: CMU's solution... >> csg@pyramid.pyramid.com (Carl S. Gutekunst) wrote: >> We got hit by an unexpected bulge of news last night (where do those >> things come from?)... In article <2523@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes: > One step that I have taken to reduce the problem is to key my outgoing > news batching on free spool space, e.g. once free space goes below 3MB, > I will not create any new outgoing batches [...] > A major problem with uucp is that it runs asynchronously to everything, We were testing MACH 1.0 on Boulder for about a week. Now, while MACH still needs work (scheduler doesnt quite handle niced proc's properly), one item it features is resource pausing. In effect, when a disk reaches it's capacity, any system call that terminated due to lack of space or inodes causes the process (thread?) to "pause". It also sends a message to the controling terminal (somewhat useless when most daemons run without one). Of course, this addresses a much wider range of problems, but with respect to News/UUCP, it did ensure that arriving news and uucp jobs were not /dev/null'd. It looks like the mods (done by Mike Accetta @ CMU) slip easily into pure BSD ('course, my kernel *needs* more stuff :-)... --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991) forys@boulder.Colorado.EDU -or- ..!{hao|nbires}!boulder!forys