> Well, NFSv3 is a stateless protocol, meaning that it shouldn't be > 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
