From owner-freebsd-hackers  Sat Feb 10 19:39:25 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA07116
          for hackers-outgoing; Sat, 10 Feb 1996 19:39:25 -0800 (PST)
Received: from Vorlon.odc.net (nwestfal@Vorlon.odc.net [206.250.32.6])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id TAA07099
          for <hackers@freebsd.org>; Sat, 10 Feb 1996 19:39:20 -0800 (PST)
Received: (from nwestfal@localhost) by Vorlon.odc.net (8.7.1/8.7.1) id TAA09916; Sat, 10 Feb 1996 19:42:50 -0800
From: Neal Westfall <nwestfal@Vorlon.odc.net>
Message-Id: <199602110342.TAA09916@Vorlon.odc.net>
Subject: Re: can't free vnode
To: terry@lambert.org (Terry Lambert)
Date: Sat, 10 Feb 1996 19:42:50 -0800 (PST)
Cc: hackers@freebsd.org
In-Reply-To: <199602102219.PAA16797@phaeton.artisoft.com> from "Terry Lambert" at Feb 10, 96 03:19:44 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
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)

> 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?

> 
> 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).  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?

Thanks for your help

Neal Westfall


> 
> 
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
>