From owner-freebsd-current Mon Mar 6 14:29:06 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA20260 for current-outgoing; Mon, 6 Mar 1995 14:29:06 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id OAA20254 for ; Mon, 6 Mar 1995 14:29:02 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id OAA03736; Mon, 6 Mar 1995 14:28:40 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id OAA02305; Mon, 6 Mar 1995 14:28:40 -0800 Message-Id: <199503062228.OAA02305@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: terry@cs.weber.edu (Terry Lambert) cc: current@FreeBSD.org Subject: Re: more ETXTBSY bugs In-reply-to: Your message of "Mon, 06 Mar 95 14:57:36 MST." <9503062157.AA19959@cs.weber.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 06 Mar 1995 14:28:39 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >I'd like to see the people seeing the thrashing problems add about 16M >of swap without doing any extra apllications and see what happens. If >the vnode pager is happy, this should be doable with a swap on file. >My immediate suspicion is that the problems would just go away until >the cache was filled again (this time consuming all of swap). We now believe that the thrashing has nothing directly to do with the page cache. Poul discovered a problem with the name cache that causes it's hit rate to decrease into the teens when the "thrashing" starts happening. After examination of the name cache contents, he found that directory vnodes were getting regularly flushed and this was causing the file vnodes to be invalid. I thought the problem had to do with the file vnodes having a reference most of the time (and thus not on the free list), but when we made some changes to give priority to reclaiming file vnodes, this didn't help. I'm now of the opinion that someone introduced a new and interesting bug in the past two weeks or so that is screwing the name cache and that our merged VM/buffer cache has little or nothing to do with it. -DG