CC'ng your suggestion to the 'kernel wizards'...right now, the only thing
I have to work with is the fact that the problems started right after I
upgraded INN to the new code...the rest is basically trying to followup
suggestions...
On Wed, 9 Jun 1999, Richard Michael Todd wrote:
> In message <pine.bsf.4.05.9906091317550.49155-100...@thelab.hub.org>you write:
> >
> >I'm currently investigating a problem with my server that
> >coincedentally(sp?) started right after I upgraded INN to what we
> >currently have...
> >
> >Someone *just* suggested that they thought that 3.2-STABLE of FreeBSD
> >still has a slight bug in MMAP that causes a race condition...it just
> >clued into me that Richard(?) sent out that response to me about Clayton
> >using mmap() more now in nnrpd to share active?
>
> It's actually sharing the group.index file, as well as mmap()ing the .IDX
> and .DAT files when needed. It'd require a lot of work to implement a
> non-mmap version of the code. Given that people like Matt Dillon are
> interested in working on the FreeBSD VM code, it's probably easier just to
> get him to fix mmap() on FreeBSD. :-)
>
> FWIW, I haven't seen any problems like that on 3.1-STABLE, but I may
> just not have enough reader load to trigger it. The use of mmap() in
> the ov3.c code isn't anything terribly exotic (i.e. not too different
> from, say, how cnfs.c or dbz uses it), and the group.index file is
> only a couple meg. The ov3.c code does do a lot of byte-range locking
> of the group.index file, though; have you and the FreeBSD kernel
> wizards considered the possibility that it may be the byte-range
> fcntl() locking code that's the problem?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scra...@hub.org secondary: scra...@{freebsd|postgresql}.org
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
