From owner-freebsd-hackers Wed Mar 6 11:52:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18308 for hackers-outgoing; Wed, 6 Mar 1996 11:52:51 -0800 (PST) Received: from schizo.cdsnet.net (schizo.cdsnet.net [204.118.244.32]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18302 for ; Wed, 6 Mar 1996 11:52:47 -0800 (PST) Received: (from mrcpu@localhost) by schizo.cdsnet.net (8.6.12/8.6.12) id LAA29412; Wed, 6 Mar 1996 11:53:44 -0800 Date: Wed, 6 Mar 1996 11:53:44 -0800 (PST) From: Jaye Mathisen To: Terry Lambert cc: hackers@freebsd.org Subject: Re: -current MMAP vs INN 1.4unoff3 In-Reply-To: <199603061915.MAA11561@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk Unfortunately I don't. All I know is that MMAP and INN work fine on several other OS's, and fail miserably under any version of FreeBSD through the 3/4 -current. While it's certainly possible that it's a defect in INN, I would be skeptical. Trivial uses of MMAP work fine. This concerns me for another reason in that we're planning on making heavy use of MSQL for processing our accounting records for our RADIUS stuff, and MSQL can use MMAP, but now I can't be sure the the implementation and thus the results of the queries is reliable. However, in the interests of narrowing it down a bit, it only seems to be problematic when a newgroup message is processed and the active file changes size as opposed to just content changing w/o size changing. Maybe it's a locking problem of some kind, I don't know, all I know is that it doesn't work, John sent me mail a couple months ago telling that he thought it worked in -current, and I'm reporting back that it still doesn't work. On Wed, 6 Mar 1996, Terry Lambert wrote: > > It's still broken, exhibits the same behaviour as a 2.1-release box, > > where it has problems with the active file. > > > > It would be nice if this would eventually get fixed, even if just for > > correctness sake, as opposed to any measurable performance increase. > > Could you provide a stand-alone regression test set of behaviour > with documented expected behaviour and exception lists? > > It would be nice if we could set up a TET or ETET framework for > regression/validation and automate this process. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. >