From owner-freebsd-hackers Wed May 29 15:54:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA18882 for hackers-outgoing; Wed, 29 May 1996 15:54:16 -0700 (PDT) Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA18873 for ; Wed, 29 May 1996 15:54:06 -0700 (PDT) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by smyrno.sol.net (8.6.11/8.6.12) with ESMTP id RAA10181; Wed, 29 May 1996 17:53:41 -0500 Received: from localhost by solaria.sol.net (8.5/8.5) id RAA04893; Wed, 29 May 1996 17:55:29 -0500 From: Joe Greco Message-Id: <199605292255.RAA04893@solaria.sol.net> Subject: Re: Breaking ffs - speed enhancement? To: smd@cesium.clock.org (Sean Doran) Date: Wed, 29 May 96 17:55:26 CDT Cc: davidg@Root.COM, terry@lambert.org, hackers@freebsd.org, rashid@rk.ios.com In-Reply-To: <96May29.144850pdt.119171-19642+41@cesium.clock.org> from "Sean Doran" at May 29, 96 02:48:46 pm X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > So what's wrong with turning off the update daemon on such machines, > or at least making it call sync(2) at much less frequent intervals? > > This is a venerable practice on far-too-busy news machines. I don't think we have a "separate" update daemon.. although the interval can be tuned with sysctl. I'm a little leery of doing this however since I believe other metadata gets written out too. > Also, another venerable practice is to make the inode cache > *huge* (tens of thousands of inodes in ninode/desiredvnodes, > as appropriate). > > I would be willing to bet that these two changes, neither > of which needs anything more than adb/gdb, and both of which > are widely portable to 4BSD systems of all types, will make your > max-ed out disks much happier. Well I'm open to suggestions. Punching up desiredvnodes may help somewhat, but I already crank up other stuff which sets that pretty high. > Now what I'd really like to see being worked on for flinging > around news too fast is playing with 4.4BSD union mounts so that > at the lowest layer one finds the oldest articles, and in > each higher layer, one finds newer articles, and the upper > layer is current. > > Expiry would then mean: > > -- stop incoming news > -- unmount lowest layer > -- newfs lowest layer > -- mount former lowest layer as upper layer > -- restart incoming news > > and then some bookkeeping as needed to adjust the history > and overview files, which probably can be done in spare > cycles. > > Unlink(2) is too bloody slow. > > You probably lose if you are doing mostly-reads on articles > several generations old. If, however, you're a big news distribution > site... If you're a big news distribution site, by definition you don't _need_ news that's several generations old, because you drop all your deadbeat feeds :-) (I keep news for a day and expire every 4 hours). Ah well. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847