From owner-freebsd-current  Wed Oct 22 09:15:44 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA08094
          for current-outgoing; Wed, 22 Oct 1997 09:15:44 -0700 (PDT)
          (envelope-from owner-freebsd-current)
Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA08086
          for <current@FreeBSD.ORG>; Wed, 22 Oct 1997 09:15:39 -0700 (PDT)
          (envelope-from Tor.Egge@idi.ntnu.no)
Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65])
	by pat.idi.ntnu.no (8.8.6/8.8.6) with ESMTP id SAA17560;
	Wed, 22 Oct 1997 18:15:14 +0200 (MET DST)
Message-Id: <199710221615.SAA17560@pat.idi.ntnu.no>
To: roberto@keltia.freenix.fr
Cc: current@FreeBSD.ORG
Subject: Re: nullfs & current UPDATE!
In-Reply-To: Your message of "Tue, 21 Oct 1997 20:38:07 +0200"
References: <19971021203807.51847@keltia.freenix.fr>
X-Mailer: Mew version 1.70 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Oct 1997 18:15:13 +0200
From: Tor Egge <Tor.Egge@idi.ntnu.no>
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 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