On Tue, 2 Mar 2010, Daniel Braniss wrote:
runing with the experimental nfs server all is ok! (at least I can't see any mbuf leakage :-) so now that we can assume that the problem is in NFS/UDP writes via classic nfsserver, where to look?
It might also be the krpc reply cache, since the experimental server isn't using it (nfsv4 requires a rather twisted reply cache and it was easier to just use that one for nfsv2,3 for the experimental server, as well).
If it doesn't go away, the problem is more likely in the krpc or the generic udp code. (When I looked at svc_dg.c, I could only spot one possible leak and you've already determined that patch doesn't help. The other big difference when using udp on the FreeBSD8 krpc is the reply cache code. I seem to recall it's an lru cache with a fixed upper bound, but it might be broken and leaking. If you change the server to set sp_rcache = NULL in the initialization function in sys/nfsserver/nfs_srvkrpc.c, I think that disables the replay cache. You wouldn't want to run this way in production, but it would determine if the leak is in it. Change the 3 lines in nfsrv_init() to: nfsrv_pool->sp_rcache = NULL; nfsrv_pool->sp_assign = NULL; nfsrv_pool->sp_done = NULL; and I think the krpc replay cache will be disabled.
If someone gets a chance to try the above (not in production mode:-), it will determine if the problem is in the reply cache or the nfs server's write code.
Good luck with it and please report back if you get to try the above.
Thanks for trying the experimental server. It is getting narrowed down, due to everyone's work on it. rick _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
