Date: Wed, 29 Jul 1998 12:49:30 -0500 (CDT) From: "Stephen D. Spencer" <bsd-isp@artorius.sunflower.com> To: isp@FreeBSD.ORG Subject: Re: inn-2.0 Message-ID: <Pine.BSF.3.96.980729121119.7247A-100000@artorius.sunflower.com> In-Reply-To: <Pine.BSI.3.95.980627135952.8883A-100000@buffnet11.buffnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Jun 1998, Steve Hovey wrote: > > > I noticed less cpu hit using CNFS - but I noted that the config defaults > active to MMAP, and CNFS is all MMAP, and the whole things just sucked to > impliment - I had to manually change config.data to not use MMAP, and had > to go back to the trad file structure to get it to work. > [...] Curious. After a short time of outsourcing usenet we are preparing to bring our local newsfeed back online using FreeBSD 2.2.6 and INND 2.1. (good-bye and good ridence to IRIX) First, I'm curious about the above comment. Perhaps I'm missing the point of this statement, but isn't it logical that a system designed to efficiently handle 750,000+ articles a day plus news readers going to cause some sort of load? Perhaps if you describe the hardware you're using it would make more sense. The real point of this message is concerning disk allocation for meta/cycbuffs. Understandably, using the traditional storage methods, concatenating hard drive space made sense. I'm curious as to what layout designs other news administrators are choosing when using CNFS. My first thought was, of course, was to configure a ccd consisting of 5-6 9 gigabyte drives on three different SCSI channels to create a gargantuan cycbuff on which to store the spool. I have an additional three 4 gigabyte drives (all baracuda's but different models) that I was thinking of using for system, history and over.view. The expiration model for storage.api methods is based on the metacybuff identifier so that would be a good indication that a single metacycbuff (or, for that matter, small numbers of large cycbuffs) would actually give less flexibility in managing which groups stay longer or shorter. I understand that if a cycbuff fills up that it will return to the top of the file and keep writing thereby, in certain aspects, superseding the expiration process. We have also been given the ability, however, to configure more than one cycbuff per metacycbuf which will then be written to in a round-robin fashion. Would it be better to keep smaller (well... 9 gig) cycbuffs tied to single drive units and simply allow INN to do its pseudo-striping rather than using ccd? It would seem that it would allow for future reallocation of space by, for example, removing a cycbuff from a metacycbuff for (everything minus alt) to the alt hierarchy without having to remake the file systems. It would also give more flexibility to the expiration process such as it is for this sort of storage method. I anxiously await your comments. Regards, Stephen --------------------------------------------------------------------- - Stephen Spencer finger gladiatr@artorius.sunflower.com for - - administrator PGP key. - - Sunflower Datavision http://www.sunflower.com - --------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980729121119.7247A-100000>