Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.Hawaii.Edu!news.uoregon.edu!hammer.uoregon.edu!csulb.edu!news.sgi.com!news.sprintlink.net!news-peer.sprintlink.net!howland.erols.net!news-peer.gsl.net!news.gsl.net!portc01.blue.aol.com!newsstand.cit.cornell.edu!news.acsu.buffalo.edu!dsinc!newsfeed.pitt.edu!bb3.andrew.cmu.edu!cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!cmcl2!newsserv.cs.sunysb.edu!news. cc.sunysb.edu!cfanning From: Chris Fanning <cfanning@jingoro.prevmed.sunysb.edu> Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: FreeBSD as news-server?? Date: 23 Oct 1996 23:09:01 GMT Organization: State University of New York at Stony Brook Lines: 71 Message-ID: <54m8id$p70@abel.ic.sunysb.edu> References: <537ddl$3cc@amd40.wecs.org> <53ott7$579@adv.IAEhv.nl> <53pm5c$5ks@twwells.com> <53u1ic$61i@flash.noc.best.net> <53ucuj$8qh@twwells.com> <540dos$asu@jingoro.prevmed.sunysb.edu> <54398m$img@twwells.com> NNTP-Posting-Host: jingoro.prevmed.sunysb.edu X-Newsreader: TIN [UNIX 1.3 unoff BETA release 961020] Well, this teaches me to ever make a post about news. I just spent the past 3 days cleaning up a huge mess after I posted this article. (I typically get 100MB of news a day, suddenly I got 600! Egads!) Thanks to everyone who pointed out that I could remount the disks. I haven't tried it yet, because part of my recovery was upgrading to 1.5b1. I'll probably try that tonight. T. William Wells <bill@twwells.com> wrote: [my stuff snipped] : One thing you have to be aware of is that the time to store an : article is (now) dominated by the time it takes to search and : update a directory. And that's proportional to the size of the : directory. : What this means is that the time to *store* an article grows : faster than the newsfeed size. For a rule of thumb, consider it : proportional to the newsfeed size times your spool size. Well, in my case, the spool size is the same size today as it was years ago. I have cut down on my expire times and what I carry considerably to compensate. : : Doing roughly the same thing today on a P133 with 64MB RAM with FreeBSD I : : get a peak of 10 art/sec. : (What disks? What disk controller? With disk I/O being the : bottleneck, these are critical.) I used to run with: Linux 1.something, 486/66, 16MB NCR 810 (5MB/s async mode only supported): 2GB Barracuda for spool 2GB Barracuda for system, history, homes, etc. I now run with: FreeBSD-stable, P5-133, 64MB NCR 810 2GB Barracuda for spool NCR 810 4GB Quantum Grand Prix for system, history, etc. 2GB Barracuda for homes So, as far as I/O is concerned, there's been nothing but a huge increase in that area. : mount -u -o async : I think will do it; it's in the man page anyway. But I don't know : if it makes much difference, though I do run that way. Most of the : time is spent in *reading* the directory -- one has to do that in : order to determine if the file already exists. Async writes don't : help there. Yup, I'm going to give this a crack. The metadata writes are primarily of concern when you create/write to a file and I think I have enough locality to properly cache most reads. As an aside, after cleaning up my huge mess, ytalk stopped working for me. I get this in syslog: Oct 23 11:55:35 jingoro talkd[341]: sendto: Address family not supported by protocol family Anyone have a clue? I did recompile the kernel, my auto-sup might have changed a few things around which broke it. Recompiled ytalk and ntalkd but I get the same thing. Now to see if I can still post.. :) (Argh! More things to fix!) Chris