Well, I just got off the phone with Sun support in regards to our NFS
problems. The symptoms of our problems are: files viewed on NFS clients
sometimes appear to be overwritten by the contents of another file.
These files are intact, however, when viewed on the NFS server. The files
that are most frequently affected at our site are .login, .cshrc and C
source files. We are experiencing the problem on SPARCstation clients
being serviced by a 3/280 server running 4.0.3, but others have reported
it with both Sun 3 and SPARC servers and clients, running OS versions 4.0.1
and 4.0.3.
According to Sun, this is a known bug (ID 1026933). Several patches
have been sent out, but with limited success. They are not currently
sending out a patch that addresses this problem. I wasn't able to
get a firm date on the availability of a patch, but Sun seems to be
aware of the serious nature of this problem.
In my initial message, I stated that accessing the file by its full
path name seems to clear up the problem. This is only partially true;
it clears up the problem with that particular file, but the problems
seem to continue on the affected client until it is rebooted.
Other readers that responded to my query seem to have correlated
the frequency of the problem with:
a) A heavy net load or heavy load on server.
b) A full file system. Typically the problem surfaces after a
"NFS write failed" message on the server.
Currently the only solutions are to:
(1) Reboot any offending clients
(2) Wait for Sun to develop a definitive patch.
Needless to say, if you are affected by this problem and haven'already done
so, call Sun support to get on the list of people who are in need of the
forthcoming patch.
Although it isn't that great a hardship to reboot when the problem
crops up, I'm greatly concerned about users not noticing the problem
in time. It's easy enough to catch problems in .login and C source
files, because their syntax is explicitly checked, but how about large
binary data files? I don't want to be around when the first user comes
to visit after noticing that conclusions he arrived at were erroneous
because he was actually viewing somebody else's data file. There is also the
problem of a paniced user saving the corrupted file from the client,
thereby overwriting the good copy on the server.
Thanks to all who replied to my original plea for help.
----------
Mark Day
Dept. of Pharmaceutical Chemistry mday@zeno.mmwb.ucsf.edu
University of California, San Francisco ..ucbvax!ucsfcgl!mday
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:56 CDT