Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc,news.software.nntp Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!uunet!in2.uu.net!199.171.20.9!news.nkn.net!news.panther.net!nemesis!uhclem From: uhclem@nemesis.lonestar.org (Frank Durda IV) Subject: Re: Why does fastrm takes so long? Followup-To: comp.unix.bsd.freebsd.misc,news.software.nntp X-Newsreader: TIN [version 1.2 PL2] Organization: The Big Blue Box Message-ID: <E4LpC0.5xM@nemesis.lonestar.org> References: <01bc0afb$f877ef90$827e1bcc@rodia> Date: Sun, 26 Jan 1997 05:45:35 GMT Lines: 23 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:34519 news.software.nntp:29584 Raul Zighelboim (mango@communique.,net) wrote: : Anyway, to make thge story short, the server can write ~8arts/s when not : expiring. fastrm would take 1/2 the day in general to remove articles. Sounds like you haven't applied the patches to the news.daily script that fix problems that occur ONLY when history and articles are NOT on the same partition. This bad code exists in 1.4unoff4 and earlier, and may still be in 1.5. The end result is that fastrm really doesn't do the expiring, it gets done by expire just as though you had not specified the use of fastrm. The problem stems from improper arguments getting passes on the expire command line. Fastrm eventually runs and finds the files already removed. On my 32GB news spool, expire would be running nearly 20 hours after it started, just in time to run again. And this was on a 300MHz dual-processor Alpha. Once the script was fixed, everything including expireover completes in about six hours. Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" or uhclem%nemesis@rwsystr.nkn.net | demand... A SEGMENT REGISTER!!!" |"A what?" or ...letni!rwsys!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983