NFS "misbehaviour" in OSx 4.1

[Anders Hillbo]

sas at pyrps5 (Scott Schoenthal) writes:

> >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.

I understand that, I still think its a serious "misfeature" cause:

1) There is a lot of unnecessary error messages on the console 
   (one msg noting "Repeated 4711 times" ala 4.3 would suffice)
   The console is unusable during that time!
   Also there is no indication of which host is causing the error so,
   how do you find the erroneous user/host???

2) The problem get worse as the user on the Sun gets no error (not
   your fault I guess) so he sometimes does not stop trying to access
   the file. We had one user doing this for 10 minutes before we found him.
   (Thats a lot of paper at the console printer...)

3) We notice a HIGHER LOAD on the server during the time condition is
   active. Also grave if its take time to find the sinner...