Date: Sun, 18 Oct 2009 01:14:54 GMT From: kickbsd <kickbsd@ya.ru> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/139715: vfs.numvnodes leak on bussy zfs Message-ID: <200910180114.n9I1Es21045435@www.freebsd.org> Resent-Message-ID: <200910180120.n9I1K1aW043297@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 139715 >Category: kern >Synopsis: vfs.numvnodes leak on bussy zfs >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Oct 18 01:20:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: kickbsd >Release: 8.0-RC1 >Organization: none >Environment: FreeBSD lab-backup012.local 8.0-RC1 FreeBSD 8.0-RC1 #3: Tue Oct 13 08:44:45 UTC 2009 root@lab-backup012.local:/usr/obj/usr/src/sys/GENERIC amd64 >Description: I have a reproducible hangs on busy zfs file system. Just run rsync to zfs server from other data source. vfs.numvnodes tends to leak and when reach kern.maxvnodes no new files can be created or modified. There is no kernel panic and already existing shell sessions works but system can not rebutted safely after vfs.numvnodes reached kern.maxvnodes. After rsync complated vfs.numvnodes never goes back to normal. I have increased kern.maxvnodes to kern.maxvnodes: 1.800.000 but vfs.numvnodes slowly grows for about 10.000 vnodes per 4 hours rsync session. Same behavior observed with relatively bussy server with ~1k rrd databases which updated every 5 min. >How-To-Repeat: Run long rsync session to zfs filesystem or run update on 1k+ rrd databases. >Fix: N/A >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910180114.n9I1Es21045435>