Subject: Bizarre bug in NFS/mmap code
To: None <email@example.com>
From: Gordon W. Ross <firstname.lastname@example.org>
Date: 07/27/1995 10:29:44
> From: David Jones <email@example.com>
> 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...