From owner-freebsd-current Thu Oct 23 11:33:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA17031 for current-outgoing; Thu, 23 Oct 1997 11:33:15 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.5.84]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA17026 for ; Thu, 23 Oct 1997 11:33:09 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.7/8.8.7) id LAA03011; Thu, 23 Oct 1997 11:33:08 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd003008; Thu Oct 23 11:33:07 1997 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id LAA29634; Thu, 23 Oct 1997 11:33:03 -0700 (MST) From: Terry Lambert Message-Id: <199710231833.LAA29634@usr02.primenet.com> Subject: Re: nullfs & current UPDATE! To: Tor.Egge@idi.ntnu.no (Tor Egge) Date: Thu, 23 Oct 1997 18:33:03 +0000 (GMT) Cc: roberto@keltia.freenix.fr, current@FreeBSD.ORG In-Reply-To: <199710221615.SAA17560@pat.idi.ntnu.no> from "Tor Egge" at Oct 22, 97 06:15:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text 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 :-) [ ... ] > > 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. I should have realized this as well; it's an obvious side effect of the destruction of the alias reference before the destruction of the object. I really think the idea of reference needs to be revisited. For example, I would like to see the name cache entry treated as a reference instance as well. To do both of these right requires some changes to the vnode recycling code. 8-(. It would be easier to do if vclean would just die... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.