leak of the vnodes

Kostik Belousov kostikbel at gmail.com
Tue Apr 6 09:24:42 UTC 2010


On Tue, Apr 06, 2010 at 11:56:28AM +0200, Petr Salinger wrote:
> >>I would expect that sum of mnt_nvnodelistsize should be vfs.numvnodes.
> >>The sum is at about 3400, but the vfs.numvnodes is at about 38000.
> >>Is my expectation correct ?
> >Not quite, reclaimed vnode is removed from mp list.
> 
> Are they in some other list ?
No. Some code path does not properly release hold count on the vnode,
most likely. Vnode is added to the free list when its hold count reaches
zero and vnode is not doomed, doomed vnode is just freed.

> 
> >Can you check
> >that vmstat -z | grep VNODE output coincides with sysctl vfs.numvnodes ?
> 
> I would say yes:
> 
> kern.maxvnodes: 31000
> kern.minvnodes: 2000
> vfs.freevnodes: 21
> vfs.wantfreevnodes: 2000
> vfs.numvnodes: 31011
> debug.vnlru_nowhere: 261
> 
> ITEM                     SIZE     LIMIT      USED      FREE  REQUESTS  
> FAILURES
> VNODE:                    480,        0,    30999,      777,   248903,      
> 0
> VNODEPOLL:                112,        0,       80,       85,       80,      
> 0
> 
> But still:
> 
> 0xffffff0003939be0 /dev/ad0s2a on / (ufs)
> 	mnt_nvnodelistsize = 570
> 
> 0xffffff000393a000 devfs on /dev (devfs)
> 	mnt_nvnodelistsize = 41
> 
> 0xffffff0003939000 /dev/ad0s2d on /opt/sid/build (ufs)
> 	mnt_nvnodelistsize = 52
> 
> There is 30000 vnodes somewhere.
Right. The leak is there.

> 
> >Also, can you unmount linprocfs before the test and see whether it
> >leaks as before ?
> >Another thing to try is set sysctl debug.disablefullpath to 1.
> 
> Done both before this test, still "hangs/leaks":
> 
> vfs.cache.numfullpathfound: 29075
> vfs.cache.numfullpathfail4: 0
> vfs.cache.numfullpathfail2: 0
> vfs.cache.numfullpathfail1: 0
> vfs.cache.numfullpathcalls: 29075
> debug.disablefullpath: 1

Can you try to narrow down the sequence of operations that is needed
to reproduce the leak ?

If not, you may add vn_printf() + ddb_backtrace to vgonel(), but this
definitely cause immense amount of spam on the console. I am not sure
how easy would it be to spot the leaking vnodes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100406/c61e1a06/attachment.pgp


More information about the freebsd-hackers mailing list