Date: Wed, 22 Oct 1997 18:15:13 +0200 From: Tor Egge <Tor.Egge@idi.ntnu.no> To: roberto@keltia.freenix.fr Cc: current@FreeBSD.ORG Subject: Re: nullfs & current UPDATE! Message-ID: <199710221615.SAA17560@pat.idi.ntnu.no> In-Reply-To: Your message of "Tue, 21 Oct 1997 20:38:07 %2B0200" References: <19971021203807.51847@keltia.freenix.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
> By using the following patch, I've been able to create and delete hundreds > of files in a nullfs mounted directory. No vnode leak as far as I can see > from the sysctl debug.numvnodes. fsck reports no missing blocks. No panic, > just works. Now that seems too easy :-) > > I know there is a comment in null_inactive() about doing nothing in there > but it seemed logical to inform the lower layer... > > PS: a similar problem is in umapfs which is based on nullfs. > > Opinions about this ? Yes. This patch causes open files to be truncated to zero length if nullfs is used to unlink the file. e.g., when A and B are different shells: A: mount -t null /tmp /mnt A. jot 1000000 1 > /tmp/test A: more /tmp/test B: rm /mnt/test # while A: is still at top of file A: # Go to bottom of file. then the last part of the file is lost. If B performes `rm /tmp/test' instead of `rm /mnt/test' then this problem does not occur. This leads me to believe that this patch has some unwanted undocumented side effects due to calling VOP_INACTIVE without regard to lowervp->usecount. An unconditional call to vrecycle (with ap->a_vp as first argument) in the end of null_inactive (after VOP_UNLOCK) might be an alternate solution with less side effects. That should cause an immediate vrele of the underlying vnode where VOP_INACTIVE is called if usecount reaches zero. - Tor Egge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710221615.SAA17560>