From owner-freebsd-isp Wed Dec 16 12:41:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07305 for freebsd-isp-outgoing; Wed, 16 Dec 1998 12:41:40 -0800 (PST) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from liquid.tpb.net (drum-n-bass.party-animals.com [194.134.94.34]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07292; Wed, 16 Dec 1998 12:41:29 -0800 (PST) (envelope-from niels@bakker.net) Received: from localhost (niels@localhost) by liquid.tpb.net (8.9.1a/8.8.8/Debian/GNU) with SMTP id VAA32483; Wed, 16 Dec 1998 21:41:14 +0100 Date: Wed, 16 Dec 1998 21:41:14 +0100 (CET) From: N To: Gary Palmer cc: freebsd-isp@FreeBSD.ORG Subject: Re: RAID solutions? In-Reply-To: <36235.913830533@gjp.erols.com> Message-ID: <981216213424.32382A-100000@liquid.tpb.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> CNFS isn't too fast. See news.software.nntp and the inn-workers@isc.org >> archives, among others. > I think that thats not 100% accurate ... the problem as I understand it is > that accessing overview data in a CNFS system is really really bad. The rest > of it is fine. However - the unified overview database is an integral part of CNFS. If one part of CNFS is slow, you can say that CNFS is slow. Only one thing counts - what the users perceive. If you choose INN 2.x with storageapi (and if you're a largish ISP) they'll see slowness beyond belief. With, say, 250 unique users daily it's bearable, above that you'll have to buy enough memory to cache ~ 2 GB of overview data for that to happen. Although it proves again that some newsreaders (slrn) are better than all others. :) (slrn doesn't suck in the complete overview data, only the new articles.) Several people are working on different solutions for the problem; see inn-workers@isc.org archives for more details and discussion, and (of course) news.software.nntp. Two of the paths currently being explored by non-ISC people are the reintroduction of traditional overview data and a change in the database format of the history.{dir,pag} files to also include the token (and still turn extendeddbz off, to keep things manageable). Anyway, to get back to the thread, do you think you need any sort of redundancy for the spool? If not, I suggest you use ccd (or if you're brave, vinom ) to stripe some disks together and mount them in various places (alt, alt.binaries, and the rest sound like good choices). -- Niels. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message