Date: Sun, 11 Feb 1996 14:03:52 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nwestfal@Vorlon.odc.net (Neal Westfall) Cc: terry@lambert.org, hackers@freebsd.org Subject: Re: can't free vnode Message-ID: <199602112103.OAA18656@phaeton.artisoft.com> In-Reply-To: <199602110342.TAA09916@Vorlon.odc.net> from "Neal Westfall" at Feb 10, 96 07:42:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602112103.OAA18656>