From owner-freebsd-isp Sun Mar 9 09:43:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02088 for isp-outgoing; Sun, 9 Mar 1997 09:43:08 -0800 (PST) Received: from alpha.risc.org (taob@trt-on1-02.netcom.ca [207.181.81.66]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA02073 for ; Sun, 9 Mar 1997 09:42:59 -0800 (PST) Received: from localhost (taob@localhost) by alpha.risc.org (8.8.4/8.8.4) with SMTP id MAA26198; Sun, 9 Mar 1997 12:42:43 -0500 (EST) Date: Sun, 9 Mar 1997 12:42:42 -0500 (EST) From: Brian Tao To: Mike Tancsa cc: isp@FreeBSD.ORG Subject: Re: Async vs sync (was Re: freebsd as a news server?) In-Reply-To: <3.0.1.32.19970309082411.00a70c90@sentex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-isp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Mar 1997, Mike Tancsa wrote: > > Also, what is the fastrm phase ? Is this a different method than the > default used in expire to remove articles ? We are running a 2.1.5 > release machine with innd 1.5.1 Yes, check your news.daily man page. My experience is with INN 1.4.x, so it may differ with 1.5.x. You can give it an argument (delayrm) that tells it to create a file with a list of all the articles to be deleted. It will not delete articles "as it goes", but instead save up the list of filenames, sort them, then delete them all at once at the end of the expiry run. I find this method works a lot faster than deleting articles while it scans your history file during an expire. Scan through your news.daily script and find the part that calls the expirerm script. Add the commands to mount your news article spool filesystems async before the expirerm script is called (you don't need to sync in between each one). Then put a sync, and those same lines after the expirerm call but without the "-o async" part. That will cause expirerm to run on asynchronous filesystems while it deletes files, then puts them back to synchronous mode afterwards. The only caveat is that each filesystem is at risk of being completely blown away if your server crashes during an expire, because of the asynchronous disk updates. You might want to try it anyway to see how much of a speed up you get. -- Brian Tao (BT300, taob@risc.org) "Though this be madness, yet there is method in't"