NFS client over udp

[Rick Macklem]

> --- On Tue, 2/22/11, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> 
> > From: Rick Macklem <rmacklem at uoguelph.ca>
> > Subject: Re: NFS client over udp
> > To: "Kirill Yelizarov" <ykirill at yahoo.com>
> > Cc: freebsd-stable at freebsd.org
> > Date: Tuesday, February 22, 2011, 2:10 AM
> > > --- On Sun, 2/20/11, Rick
> > Macklem <rmacklem at uoguelph.ca>
> > wrote:
> > >
> > > > From: Rick Macklem <rmacklem at uoguelph.ca>
> > > > Subject: Re: NFS client over udp
> > > > To: "Kirill Yelizarov" <ykirill at yahoo.com>
> > > > Cc: freebsd-stable at 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