Subject: Re: kern/1265: Bizarre bug in NFS/mmap code
To: David Brownlee <D.K.Brownlee@city.ac.uk>
From: John Dyson <dyson@freefall.cdrom.com>
List: current-users
Date: 07/25/1995 09:23:37
> 
> 
> On Mon, 24 Jul 1995, Chris G Demetriou wrote:
> 
> > > >Description:
> > > 	I have a file NFS mounted from a SunOS 4.1.3u1 fileserver onto various
> > > 	machines. One of which is a sun4 running NetBSD -current (muon)
> > > 	It used to be       "abs culf dp myth norm nostra socrates tjfas tugs"
> > > 	It was changed to   "abs culf dp myth norm nostra tjfas tugs"
> > > 	'cat' on muon gives "abs culf dp myth norm nostra tjfas tugs"
> > > 	'vi' on muon gives  "abs culf dp myth norm nostra socrates tj"
> > > 
> > > 	vi, cat, more, (other editor), on various other machines give the
> > > 	correct result.
> > 
> > this is a mmap vs. buffer cache problem.
> > 
> > you'll note that the new file's length is correct (don't forget that
> > trailing newline, which vi will add if there's not one in the
> > file...), but that the data is correct.
> > 
> 	I guessed it was something like that :)
> > 
> > the solution: merge the vm system and buffer cache.  weekend project,
> > eh?  8-)
> > 
> 	Hmm - my weekends don't come in that shape :)
> 	Haven't the freebsd team already done this?
> 	Is anybody working on this for netbsd, and/or is it possible to
> 	take the work already done by the freebsd people?
> 
> 		David
> 
We did do the VM/buffer cache merge, but I can tell you that I don't think
there is a good (optimum) way to do it :-).  The problem is with the vastness
of the change.  On FreeBSD we are taking a step by step approach with a vision
of where it should go.  The first step that we have taken is to compatibly
implement it using the buffer cache.  We will probably continue to use the
buffer cache mechanism, but on a case-by-case basis eliminate it (e.g. UFS),
except for perhaps meta-data.  Also, LFS probably deserves special treatment.
It is very tricky to get it working correctly with filesystems with
blocksizes smaller than a page.  Also, a policy needs to be developed on
how many dirty buffers or pages are allowed before flushing them.  Of course,
64MB or 256MB of dirty buffers can be fairly slow to flush...  FreeBSD
has a relatively conservative policy on the number of buffers allowed to be
dirty.

The biggest side effect of the FreeBSD implementation is that unused
memory is available for buffer caching, while our old scheme limited the
cache size to about 2-3MB for a 16MB system.  It is bad to allow the buffer
cache to compete with the memory in processes.. But we have resolved that
with a conservative policy that appears to work.

Other strange effects can occur because of  the large number of VM objects
that are cached in the FreeBSD implementation.  Various other team members
and contributors have really helped to shake those problems out.

The end result of the FreeBSD scheme is a buffer caching scheme that appears
to have no untoward side-effects, while giving the advantages of coherency
and dynamic sizing.  It would be excessively difficult to integrate the
FreeBSD code into NetBSD, because the VM systems have almost totally
diverged, however there might be some lessons to be learned from the FreeBSD
experience.

John
dyson@root.com