Date: Thu, 04 Mar 2010 09:03:37 +0200 From: Daniel Braniss <danny@cs.huji.ac.il> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: stable@freebsd.org, freebsd-fs@freebsd.org, Willem Jan Withagen <wjw@digiware.nl>, =?utf-8?B?RWlyaWsgw5h2ZXJieQ==?= <ltning@anduin.net>, rwatson@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com> Subject: Re: mbuf leakage with nfs/udp (was mbuf leakage with nfs/zfs?) Message-ID: <E1Nn55u-000Ik6-9C@kabab.cs.huji.ac.il> In-Reply-To: <Pine.GSO.4.63.1003031936170.29530@muncher.cs.uoguelph.ca> References: <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <E1Nl6VA-000557-D9@kabab.cs.huji.ac.il> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> <BD8AC9F6-DF96-41F9-8E92-48A4E5606DC7@anduin.net> <4B89943C.70704@digiware.nl> <20100227220310.GA65110@icarus.home.lan> <Pine.GSO.4.63.1003011703100.26054@muncher.cs.uoguelph.ca> <E1NmPHy-0009jy-Dj@kabab.cs.huji.ac.il> <Pine.GSO.4.63.1003021947470.3879@muncher.cs.uoguelph.ca> <E1NmkOe-000PSY-JT@kabab.cs.huji.ac.il> <Pine.GSO.4.63.1003031936170.29530@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
>
>
> On Wed, 3 Mar 2010, Daniel Braniss wrote:
>
> > disabling the krpc reply cache does it, no visible damage. Somehow
> > this reminds me of my old 1970 beetle, parts would fall off but it would
> > continue working :-)
> > where to go from here?
> >
> Ok, so it sounds like the leak is in the krpc reply cache code, if I
> understand this? (ie. you are running the regular server with the reply
> cache disabled and the UDP client mounts aren't causing the leak.)
correct. The interesting side effect, is that I can't see any negative
issues when disabling the cash.
>
> Good work on tracking this down!
>
it was a coordinated efford :-)
> I guess the next step is to look through the code for the leak. I'll
> do that someday, but if anyone else is inspired to do so, they are
> more than welcome.:-)
>
> Thanks for working through this, rick
thank you! I have a vested interest in having this fixed, on the other hand
nfsd
seems ok, I have been running it now on a semi production server and
it's holding up quiet nicely, the cache seems not up to expectations:
store-mg-03# nfsstat -se
Server Info:
Getattr Setattr Lookup Readlink Read Write Create Remove
48176764 262687 12582599 19732 4225907 9186574 780793 818837
Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access
7623 160 27753 59551 59552 118216 0 1992779
Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId SetClIdCf
0 979005 19 0 1644267 0 0 0
Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH Lock
0 0 0 0 0 0 0 0
LockT LockU Close Verify NVerify PutFH PutPubFH PutRootFH
0 0 0 0 0 0 0 0
Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create
0 0 0 0 0 0
Server:
Retfailed Faults Clients
0 0 0
OpenOwner Opens LockOwner Locks Delegs
0 0 0 0 0
Server Cache Stats:
Inprog Idem Non-idem Misses CacheSize TCPPeak
307 0 297 80943198 0 0
danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1Nn55u-000Ik6-9C>