Date: Sun, 30 Sep 2001 23:46:27 -0500 From: Alfred Perlstein <bright@mu.org> To: Matt Dillon <dillon@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_cache.c vfs_subr.c src/sys/sys vnode.h Message-ID: <20010930234627.R59854@elvis.mu.org> In-Reply-To: <200110010433.f914XZd11860@freefall.freebsd.org>; from dillon@FreeBSD.org on Sun, Sep 30, 2001 at 09:33:35PM -0700 References: <200110010433.f914XZd11860@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@FreeBSD.org> [010930 23:33] wrote: > dillon 2001/09/30 21:33:35 PDT > > Modified files: > sys/kern vfs_cache.c vfs_subr.c > sys/sys vnode.h > Log: > After extensive testing it has been determined that adding complexity > to avoid removing higher level directory vnodes from the namecache has > no perceivable effect and will be removed. This is especially true > when vmiodirenable is turned on, which it is by default now. ( vmiodirenable > makes a huge difference in directory caching ). The vfs.vmiodirenable and > vfs.nameileafonly sysctls have been left in to allow further testing, but > I expect to rip out vfs.nameileafonly soon too. > > I have also determined through testing that the real problem with numvnodes > getting too large is due to the VM Page cache preventing the vnode from > being reclaimed. The directory stuff made only a tiny dent relative > to Poul's original code, enough so that some tests succeeded. But tests > with several million small files show that the bigger problem is the VM Page > cache. This will have to be addressed by a future commit. Is _this_ the one that was messing up that guy where we kept running out of vnodes? :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010930234627.R59854>