Subject: Bizarre bug in NFS/mmap code
To: None <dej@eecg.toronto.edu>
From: Gordon W. Ross <gwr@mc.com>
List: current-users
Date: 07/27/1995 10:29:44
> From: David Jones <dej@eecg.toronto.edu>
> Date: 	Tue, 25 Jul 1995 20:01:55 -0400

> It has been my experience that mmap() and NFS generally don't mix.  This is
> as true on SunOS as it is for NetBSD.

> Consider VM and mmap(): the VM system must maintain consistency with the
> backing object.  The Mach VM system uses special pagers to do this, and I
> think the vnode_pager, which allows mapping to files, does a good job of
> keeping VM in sync with local filesystem data.  But it doesn't do so well
> with NFS.
> 
> The main problem occurs when you access the file while the system still
> has stuff cached.  Let's assume you access a file just before it's updated
> on another node.  In this situation, your caches are out of date due to
> the update.
> 
> If a change is made on a remote host before the attribute cache expires
> then you won't see the change.  If a change is made after the attribute
> cache expires but before the data cache expires, then you won't see any
> changes that were made to the fragment of the file present in the data
> cache.  If you read past that fragment, you may get new data while keeping
> the old data.

The problem is that when the vnode_pager finds a page backed by NFS
it does not verify its "freshness" at all.  The NFS filesystem needs
a special pager that does "freshness" checks when activating a page.

Sun's VM system deals with this by letting each filesystem determine
what "pager" (segment driver) will be used for each object.  The NFS
getpage function checks "freshness" of things when reclaiming a page.

Some day, I'd like to make our VM capable of this flexibility...

Gordon Ross