Newsgroups: news.software.b
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!hybrid!robohack!eci386!lsuc!sq!msb
From: msb@sq.sq.com (Mark Brader)
Subject: C News and local postings
Message-ID: <1991Apr29.202116.21681@sq.sq.com>
Organization: SoftQuad Inc., Toronto, Canada
References: <1991Apr25.181041.6023@mp.cs.niu.edu> <1991Apr25.223301.27280@world.std.com>
Date: Mon, 29 Apr 91 20:21:16 GMT
Lines: 50

Geoff Collyer (geoff@world.std.com) writes:

> A change that just missed the last patch and should be in the next one is
> that inews will (finally) invoke newsspool or rnews instead of relaynews...

I certainly hope *not*.

At sq, we have /usr/spool/news/in.coming configured to be on a separate
filesystem from /usr/spool/news.  In.coming is on a filesystem used for
other purposes, but from which news can "borrow" large amounts of space
for, say, a period of a few days; /usr/spool/news is dedicated to news.

By doing this, we can run /usr/spool/news *much* closer to the safety
threshold than would otherwise be tolerable, and thus run with considerably
longer expiry times than otherwise possible.  I can't imagine anyone who
values their news feed doing it any other way -- well, not unless either
(a) they have so much disk space that expiry is not an issue, (b) they have
so *little* disk space that they can't spare any more for in.coming, or
(c) political or technical reasons prevent it.

(Digression: one possible technical reason is that, unless it's changed
since I last looked, C News has no configuration option to split the
filesystems this way; so one either has to use symbolic links, which
not everybody has, or one has to do a lot of local patching.)

Since we adopted this configuration we have *never* lost news due to
filesystem overflows, even when upstream glitches have held things up
so badly that, when the logjams broke, we would get 2-3 times the regular
volume for 2-3 days running.

But what this means is that, when such an event happens, sometimes we
have news sitting in in.coming for longer periods than usual, occasionally
even longer than 2 days.  It is not tolerable that, when this happens,
locally originated postings should be held up for that length of time.
(Among other reasons is that we use news internally as our corporate
"bulletin board".)

In recent releases of C News, inews has checked whether /usr/spool/news
was full to the safety threshold before allowing even a local posting;
we have had to disable this.  If inews is now to be changed to throw the
local postings in with all the delayed batches in in.coming, it will be
a much greater inconvenience.  Geoff and Henry, please do not ruin the
successful news configuration that we have arrived at.

-- 
Mark Brader			"Bad news disturbs his game; so does good;
SoftQuad Inc., Toronto		 so also does the absence of news."
utzoo!sq!msb, msb@sq.com				-- Stephen Leacock

This article is in the public domain.
