>    Well, NFSv3 is a stateless protocol, meaning that it shouldn't be
quoted text
>    possible for the client to hold server resources open.  If there is
>    a file descriptor leak on the server side its 99% sure to be a bug
>    on the server.
>
>    TCP reconnections should have no effect on the server's descriptor
>    handling.  It's really unlikely that DFly would be reconnecting anyway,
>    unless you noticed really long stalls while testing.

Yep. When I took a quick look at FreeBSD7 sources, the "openfiles" is
incremented by falloc(). It isn't called anywhere within the nfs code,
but is called for socket descriptors, which was why I thought it might
be ticking up due to lots of TCP connections being created. (A quick test
using my server code running in FreeBSD7 shows that openfiles only gets
incremented by 1 for each TCP connection and doesn't seem to change at all
otherwise.)

But, since he reports that isn't the case, I have no idea what would make
"openfiles" get incremented by the nfs server. I do agree that it is most
likely a server bug (fortunately not the server code I'm maintaining these
days:-).

rick