NFS stale buffers

[Tom Barron]

The scenario: 

A user on a 3/50 workstation running 3.5 is in an edit & compile cycle,
editing from the workstation and compiling on a Sun4/280 running 4.0.1.
The file being edited and compiled is served via NFS from a 3/180 running
3.5.

The problem:

Saves in the edit session don't show up on the 4/280, or at least not
regularly and in time for the compiles.  Presumably both the 3/50 and the
4/280 are buffering file data.  The 3/50's buffers are getting flushed to
disk since the updates are apparent on both the 3/50 and the 3/180 server.
But reads on the 4/280 work with old buffers that don't reflect the
updates.  Output from 'ls' commands on the three machines is consistent
with this - i.e., the 3/50 workstation and the 3/180 server both show the
same, later modification date that that shown on the 4/280.

The question:

Is this a bug?  We never observed this phenomenon till we upgraded the
4/280 from 3.2 to 4.0.1.  On the other hand, since NFS is a stateless
protocol on the server side, the server can't be responsible for notifying
the 4/280 client that the file has been written and the 4/280's buffers
for the file are invalid.  So my question becomes one of what NFS clients
do.  Presumably they are allowed to buffer data (nothing in the Sun NFS
protocol doc addresses this).  One could imagine that the client would
buffer data but still check to see if the inode on the file shows a new
modification date and discard its buffers if it does ....

I've not gotten a response on this yet from Sun Software support.
Probably it would be most appropriate to respond to me directly and I'll
summarize back to the net.

Tom Barron		internet:	thos at cs.uchicago.edu
Computer Science			thos at gargoyle.uchicago.edu
University of Chicago	bitnet		thos%gargoyle at uchimvs1.bitnet
(312) 702-8850		uucp		...uunet!gargoyle.uchicago.edu!thos