Date: Tue, 27 Aug 1996 09:26:03 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@Root.COM Cc: matthew@scruz.net, hackers@freebsd.org, matthew@nic.scruz.net Subject: Re: questions Message-ID: <199608271626.JAA24851@phaeton.artisoft.com> In-Reply-To: <199608270725.AAA16651@root.com> from "David Greenman" at Aug 27, 96 00:25:20 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >1. I have an application (one which, if I finish it, will be given away to > > the net community at large) which to provide a huge performance increase > > over its former incarnations uses mmap heavily. It doesn't do any other > > I/O on the mmap'ed files, but it does do a lot of mmap. The INN lists > > indicate that FreeBSD and mmap don't get along, but since I've been > > switching the company over to FreeBSD systems (we'd started with NetBSD) > > I'd rather just use another one of those to develop and tune this on. > > Are these rumors true? Was there a fix? > > There aren't any specifically know problems with using mmaped files in > 2.1.5. We think the problem with INN has to deal with extending a mapped > file, and this might be an INN bug in dealing with mmap correctly. I second this. The problem is when the file length is less than the page boundry for the mapping region, and is rounded to a page boundry. Then, when the file is written in the page that was not in the mapping area when the mapping was created, there is no notification that the write has occurred. As a result, the in core backing store is incorrectly updated from the process address space, and, depending on order, one set of changes or the other is lost. Other than using the mmap() stdio library from Winter 92 Usenix (if memory serves correctly), making the buffered I/O mechanism interact "correctly" with mmap() is a lost cause. There is no way to get "expected" behaviour. This usage doesn't "fail" with SVR4 or Solaris, since they do not have a unified VM/buffer cache. The quotation of "fail" is intentional: I mean that the failure still occurs, but since the data can be used consistently by INN, it doesn't raise its head as an obvious flaw; however, one set of data or the other *is* lost. There was a nice test program that kicked out this flaw (no, not the comprehensive mmap tests, where FreeBSD glowed compared to all other OS's -- just a small test program written by one of the INN guys and posted to -current). The flaw is, in fact, in the usage assuming that the caches are not unified, and that the write of the mapping region tail data will be truncated at the former file length when written back to disk. It is "pilot error". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608271626.JAA24851>