Date: Mon, 6 Jan 1997 15:35:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.ORG, henrich@crh.cl.msu.edu Subject: Re: MMAP Troubles (Joerg?) Message-ID: <199701062235.PAA12791@phaeton.artisoft.com> In-Reply-To: <Mutt.19970104114334.j@uriah.heep.sax.de> from "J Wunsch" at Jan 4, 97 11:43:34 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have an oppourtunity for the MMAP person (Appears to be Joerg by > > the .c, but cant tell for sure :) > > Certainly not me, rather John Dyson. But doesn't matter. > > > Anyway, I have a big beefy pentium pro system here for use as news > > that im going to roll out in a few weeks. INN w/ MMAP causes the > > NULL trashed active file, interested in working on the problem with > > a system at your beck and call? > > IIRC, the last word on INN w/ mmap() was that INN uses mmap() against > the specs in that it tries to shorten (or extend) the file while it's > being mmap()'ed. This only incidentally works on SysV's. > > All this is hearsay, so maybe John or somebody else will tell you more > exactly. Rather, it "doen't fail on non-unified cache machines"... basically because a fault causes a copy (remember bmap()?) and the backing store for the mapped region is one type of cache and the backing store for the vnode is another... It "fails" on FreeBSD because when the file is extended, a partial page is generated, but since the mapping can only go in jumps of full pages, the difference between the previous end of file and the next page boundry is now screwed beyond recognition. This is especially the case if it was using a frag for the last partial page (the use of an 8 bit 512 byte bitmap for partial pages has been discussed; however, this is not a generic soloution; for instance, a 68040 machine with an 8k page size and a 512 byte disk block size would show the errors again when a 512k on an odd 1K boundry were added to the mappable region). Part of the "fix" is to provide a mechanism for device/offset instead of vnode/offset caching, then use the device/offset for mmap instead of referencing the buffers out of the vnode. Alternately, the extention operation must change the mapping, expanding the in core buffer from the prvious fragmentary validity to the page boundry. Ideally, we could pass a "-1" or "0" or som othe magic number in to indicate that the mapping should be dynamically expanded, if possible. Of course INN doesn't use it this way... This has really been discussed to death... INN's assumptions are invalid; for historical compatability, BSD should probably validate the assumptions by going through the extra motions on a file extend, but it currently does not do so. Regards, 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?199701062235.PAA12791>