Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!cornell!uw-beaver!rice!sun-spots-request
From: pereira@warbucks.ai.sri.com (Fernando Pereira)
Newsgroups: comp.sys.sun
Subject: Re: Bizarre nfs problem
Keywords: SunOS
Message-ID: <3777@kalliope.rice.edu>
Date: 8 Jun 89 02:07:53 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 27
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 8, Issue 24, message 3 of 10

We have also seen this problem in a similar configuration. What seems to
be happening is the following

1.	3.X NFS client renames "foo" to "foo~" on 3.X NFS server
2.	3.X NFS client creates new file "foo" on 3.X NFS server
	(this seems to be the sequence of events on a GNU Emacs save)
3.	4.0.X NFS client sees the old directory entry for "foo" but
	also the new directory entry for "foo~", hence the two
	different file names with one link each but the same inode.
4.	Some time later (when the system administrator starts trying
	to help the confused user and thus creates some disk activity
	flushing buffers (-:)) the 4.0.X client starts seeing things
	consistently.

One hypothesis here is that the old directory entry for "foo" is in
directory block i, while the new entry for "bar" is in block j. The "ls"
sees a cached version of i but the new version of j. Eventually the cache
is flushed, the new block i is read back, and things appear consistent
again. Someone more knowledgeable in kernel/NFS matters might be able to
say whether this hypothesis is at all reazsonable.  We've seen this
problem only on a almost unloaded 4.0.X client; the lifetime of the
problem has varied from over 10 minutes to just a few seconds. Marvels of
distributed, stateless, asynchronous file systems...

Fernando Pereira
AI Center
SRi International