> --- On Tue, 2/22/11, Rick Macklem <rmack...@uoguelph.ca> wrote: > > > From: Rick Macklem <rmack...@uoguelph.ca> > > Subject: Re: NFS client over udp > > To: "Kirill Yelizarov" <ykir...@yahoo.com> > > Cc: freebsd-stable@freebsd.org > > Date: Tuesday, February 22, 2011, 2:10 AM > > > --- On Sun, 2/20/11, Rick > > Macklem <rmack...@uoguelph.ca> > > wrote: > > > > > > > From: Rick Macklem <rmack...@uoguelph.ca> > > > > Subject: Re: NFS client over udp > > > > To: "Kirill Yelizarov" <ykir...@yahoo.com> > > > > Cc: freebsd-stable@freebsd.org > > > > Date: Sunday, February 20, 2011, 9:02 PM > > > > > --- On Fri, 2/18/11, Kirill > > > > Yelizarov > > > > > > > On Fri, Feb 18, 2011 at > > 05:27:00AM > > > > > > > -0800, Kirill Yelizarov wrote: > > > > > > > > I have a reproducible memory > > leak when > > > > using nfs > > > > > > > client with an old > > > > > > > > nfs server > > > > > > > > > > and mbufs used > > > > > 8193/1722/9915 mbufs in use > > (current/cache/total) > > > > > 8192/1264/9456/25600 mbuf clusters in use > > > > (current/cache/total/max) > > > > > 8192/605 mbuf+clusters out of packet > > secondary zone in > > > > use > > > > > (current/cache) > > > > > 0/768/768/12800 4k (page size) jumbo > > clusters in use > > > > > (current/cache/total/max) > > > > > 0/0/0/6400 9k jumbo clusters in use > > > > (current/cache/total/max) > > > > > 0/0/0/3200 16k jumbo clusters in use > > > > (current/cache/total/max) > > > > > 18432K/6030K/24462K bytes allocated to > > network > > > > (current/cache/total) > > > > > 0/0/0 requests for mbufs denied > > > > (mbufs/clusters/mbuf+clusters) > > > > > 0/0/0 requests for jumbo clusters denied > > (4k/9k/16k) > > > > > 0/0/0 sfbufs in use (current/peak/max) > > > > > 0 requests for sfbufs denied > > > > > 0 requests for sfbufs delayed > > > > > 0 requests for I/O initiated by sendfile > > > > > 0 calls to protocol drain routines > > > > > > > > > > Kirill > > > > > > > > > You could try the attached patch. It fixes the > > only places > > > > in the > > > > client side krpc over udp that seems mights cause > > a leak. I > > > > have no > > > > idea if it will help, since these cases should > > rarely, if > > > > ever, > > > > happen in practice. > > > > > > > > Please let us know if you have the chance to try > > the patch > > > > and > > > > whether or not it helped. > > > > > > > > rick > > > > > > > Rick, i tried your patch. Fortunately it didn't help > > me. There are no > > > warnings on console and memory is climbing up during > > syncs and not > > > freed later. I'll try to switch to tcp this evening. > > Thanks for help > > > > > I'll assume that's unfortunately;-) Since the two cases > > patched probably > > never happen, I'm not surprised. > > > > The only other thing I can think of that you could try is > > switching to > > the experimental client. This would identify if the bug is > > in the regular > > client or somewhere further down in the rpc transport. > > > > The mount command would look something like: > > # mount -t newnfs -o nfsv3,udp <server>:<path> > > <mntpath> > > > I added options NFSCL to my kernel and tried to mount. mount shows > everything is ok: > 192.168.0.35:/home on /mnt (newnfs) > but when i try to cd /mnt i get permission denied > my export allow root and everything is done as root. What am i doing > wrong? > Try adding the "resvport" option. I don't think it's a default for the experimental client at this time. (I have a series of patches for the client that will go into head in April that brings it in line with the regular client, including same default mount options.)
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"
