Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!news.cps.udayton.edu!news.engr.udayton.edu!blackbird.afit.af.mil!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!news.inc.net!news.sol.net!brasil.moneng.mei.com!not-for-mail From: jgreco@brasil.moneng.mei.com (Joe Greco) Newsgroups: news.software.nntp,comp.unix.bsd.freebsd.misc Subject: Re: FreeBSD 2.1.5, INN 1.4unoff4, and mmap() Date: 16 Jul 1996 09:12:47 -0500 Organization: Marquette Electronics, Inc. - Milwaukee, WI. Lines: 66 Distribution: inet Message-ID: <4sg80v$3uu@brasil.moneng.mei.com> References: <mandrews.837437077@bob.wittenberg.edu> <4sdk50$9cp@news.demos.su> <4sdndm$27k@brasil.moneng.mei.com> <4se8tq$sgf@news.demos.su> NNTP-Posting-Host: brasil.moneng.mei.com Xref: euryale.cc.adfa.oz.au news.software.nntp:24441 comp.unix.bsd.freebsd.misc:23739 In news.software.nntp article <4se8tq$sgf@news.demos.su>, andy@sun-fox.demos.su (Andrew A. Vasilyev) wrote: :Joe Greco (jgreco@brasil.moneng.mei.com) wrote: :> Why would you want to do this on a news server, anyways? : : 1. Stripping is good :) My point was why would you care about overall disk bandwidth, so why would you run a bandwidth test? : 2. Stripping is good not only for increasing the space but : for reducing load on 1 spindel, or, in other words, : increasing the performance of the whole system. : 3. There is a way of writing the metadevice drivers in such : a way that performance is proportional to the number of drives : (for so called RAID level 0) - not "Tot_speed = N * Disk_speed", : but x*N, x -> 1.0 :) (ODS as an example). : 4. FreeBSD metadevice (concatenated device) does not satisfy (3) - : but I hope it would. Hmm, well, for some of us, using ccd as I've described, we've seen performance boosts. : 5. That is why I use concatenated devices, and that is why I've : written to *.freebsd :) : :> Use a _large_ stripe size to increase available concurrency of accesses. : : ??? To increase the _concurrency_ one should have the stripe size : -> 1 cyl. for large files (to W/R the file simultaneously to/from : many spindels), or ~S for small file size when writing/reading multiple : files a time. "~S"? If you mean the size of the article, you are wrong. :> You don't care about how FAST you can retrieve your 1K or 2K Usenet articles :> off of the disk. You will not derive a benefit from striping from :> bandwidth. You care about how MANY you can get off your disks in as short a :> period as possible. If you have four drives, you would ideally like to be :> able to saturate the device and have each drive doing a complete article :> fetch without involving other drives. : : So the stripe size should be ~2K - the mean size of USENET article : (not alt.binaries :)). No, you're forgetting - to retrieve an article requires multiple accesses. You need to do multiple directory lookups, etc. If you really think about it, the clearest solution is to make sure that the article and its parent directory both get read by the same drive - that way you do not have two drives "shadowing" each other, one to get the directory, one to get the article. You want the one mechanism to be autonomous. :> I use a stripe size of 65536. And it really works well. : : Well, I've got the best results for 64K and 128K - but I've : measured large sequential read, not little files. Yes, that's the problem. Optimizing for large sequential reads is close to useless on a Usenet spool. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968