From owner-freebsd-hackers Sun Feb 11 13:07:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA24882 for hackers-outgoing; Sun, 11 Feb 1996 13:07:46 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA24875 for ; Sun, 11 Feb 1996 13:07:43 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18656; Sun, 11 Feb 1996 14:03:52 -0700 From: Terry Lambert Message-Id: <199602112103.OAA18656@phaeton.artisoft.com> Subject: Re: can't free vnode To: nwestfal@Vorlon.odc.net (Neal Westfall) Date: Sun, 11 Feb 1996 14:03:52 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <199602110342.TAA09916@Vorlon.odc.net> from "Neal Westfall" at Feb 10, 96 07:42:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org Precedence: bulk > > There are two occasions when this happens; the first is in a very low > > RAM condition when you fill up swap. The fix is to add more swap. > > We have a 100 MB swap partition on this machine. Is this adequate? > (keeping in mind the machine has 32MB ram and it is a news server) Since it is a news server, the amount of swap you need is higher than if it weren't. If it repeats with some frequency, you can use the "vmstat" command to check the amount of free swap. See the "vmstat" man page for details. > > The easiest workaround for now is to make sure you have sufficient > > free vnodes by jacking up the desiredvnodes. > > Is this something we can change in the kernel configuration? Or the > source? Or is this something we need to patch in INN? This is something you can change in the source. You need to look at the /sys/kern/vfs_init.c code. > > A less easy workaround would be to call VOP_ISLOCKED() on the vp in > > vrele() in /sys/kern/vfs_subr.c, and if it is, go to sleep on the > > address until it isn't. This would be something like: > > > > while( VOP_ISLOCKED(vp)) { > > (void) tsleep( (caddr_t)vp->v_data, PINOD, "vfslk", 0); > > } > > > > This is gross, but works because vp->v_data is the same address as the > > inode that VOP_UNLOCK(vp) calls the wakeup on in the FS's that use the > > recursion semantics for potential dissociation of the vnode from the > > underlying FS (see the vclean() comments in vfs_subr.c)... the address > > of the per FS inode data. > > Which method would you recommend? (I'm no kernel hacker, but I'm > perfectly comfortable with applying any patches if it will help). My gut reaction is to fix the hash and get rid of the vnode/fs code that does the disassociation entirely, movining the vp locking up into the common code. This is non-trivial, but it does mean that the dragon would only have to be fought once generally, instead od once per file system type. For you, either cranking the swap or the desiredvnodes will have the effect of letting you ignore the bug. The patch suggested above will "make it go away", but is a kludge, not a fix. > Also, is it true that this problem has been fixed in 2.2-current? Any > chance the fixes will make it into 2.1-stable? >From John's response, I think that it is *not* fixed in -current. He and I have talked about changing the cache so that the ihash code is not necessary, but it hasn't even reached a good design stage (unless John has gone and implemented it already -- he is a maniac 8-)); the idea is one from a coworker of mine from a related project that uses the BSD code in a product. I think if real fixes are made, it will be next release before they make it into a -stable. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.