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