Date: Sat, 10 Feb 1996 19:42:50 -0800 (PST) From: Neal Westfall <nwestfal@Vorlon.odc.net> To: terry@lambert.org (Terry Lambert) Cc: hackers@freebsd.org Subject: Re: can't free vnode Message-ID: <199602110342.TAA09916@Vorlon.odc.net> In-Reply-To: <199602102219.PAA16797@phaeton.artisoft.com> from "Terry Lambert" at Feb 10, 96 03:19:44 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)
> 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.
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602110342.TAA09916>