Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!apple!voder!pyramid!sas
From: sas@pyrps5 (Scott Schoenthal)
Newsgroups: comp.sys.pyramid
Subject: Re: Strange Ether-problem on Pyramid (drops small amount of packets)
Message-ID: <34111@pyramid.pyramid.com>
Date: 4 Aug 88 16:57:33 GMT
Sender: daemon@pyramid.pyramid.com
Reply-To: sas@pyrps5.pyramid.com (Scott Schoenthal)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 28

In article <502@draken.nada.kth.se> ahi@nada.kth.se (Anders Hillbo) writes:
>By the way, the 4.1-860601 has a (minor) NFS bug (SunOs 3.4 clients)
>when:
>a) a process on a client has a file on the server open.
>b) someone removes that file on the server.
>c) the client process tries to access the file
>Result:
>c) a lot of of error messages appear on the server console and the load gets
>   high on the server. The user gets no error msg at all!
>
>Typical error msg (repeated *many* times):
>ufs_vget: iget(0x82a, 0xfecec000, 8803) gen mismatch 15/16
>fhtovp failed:  8 8803 15

The message indicates that an incorrect file handle is being used by an
NFS client.  Remember that NFS is "stateless" relative to the server.
By removing the file on the server, you have invalidated the client's
reference (handle) to the file.  If the client later attempts to the use
this handle, the server (Pyramid) will reject it with an error (returned
to the client process by most Sun-based NFS implementations as ESTALE).
The "gen mismatch" refers to the fact that the generational field in
the client's version of the handle does not match the same field in the
referenced inode.

sas
----
Scott Schoenthal   			sas@pyrps5.pyramid.com
Pyramid Technology Corp.		{sun,hplabs,decwrl}!pyramid!sas