Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!cbmvax!grr
From: grr@cbmvax.cbm.UUCP (George Robbins)
Newsgroups: net.news.b
Subject: Re: Inews vs. df
Message-ID: <608@cbmvax.cbmvax.cbm.UUCP>
Date: Sun, 10-Aug-86 13:00:35 EDT
Article-I.D.: cbmvax.608
Posted: Sun Aug 10 13:00:35 1986
Date-Received: Tue, 12-Aug-86 10:07:43 EDT
References: <2400@phri.UUCP> <1299@lsuc.UUCP> <543@spar.SPAR.SLB.COM>
Reply-To: grr@cbmvax.UUCP (George Robbins)
Organization: Commodore Technology, West Chester, PA
Lines: 25

In article <543@spar.SPAR.SLB.COM> faunt@spar.UUCP (Doug Faunt) writes:
>
>Michael Ellis, who set up the system here, set up something he calls
>"prune" that trims individual directories in a script, so that some
>news-groups stay around longer than others.  This is fine, and seems
>to work well, BUT our history file is continuously growing.  What do
>people think is the best way of getting the history file back in sync
>(and smaller)?

The simplest solution is to do an 'expire -r' on an occasional basis.
If you are using the 'DBM' option for the history file, this is the only
easy way to trim the history file. If you aren't using this option, then
you can clean up the file anyway you choose, but it is important to do
so, since history file searching is one of the things than makes news
slow.

If you only store a small amount of news < 5MB, the the expire -r is no
big deal, but if you have 50-100MB of news stashed away, it can take
hours and eat up all your /tmp space for sort work files.  However,
running it monthly would probably be ok.
h
-- 
George Robbins - now working with,	uucp: {ihnp4|seismo|caip}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@seismo.css.GOV
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)