From owner-freebsd-current Sun Oct 19 18:43:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA16374 for current-outgoing; Sun, 19 Oct 1997 18:43:20 -0700 (PDT) (envelope-from owner-freebsd-current) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA16364 for ; Sun, 19 Oct 1997 18:43:11 -0700 (PDT) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id UAA05747; Sun, 19 Oct 1997 20:43:01 -0500 (EST) From: "John S. Dyson" Message-Id: <199710200143.UAA05747@dyson.iquest.net> Subject: Re: nullfs & current In-Reply-To: <19971019233243.25894@keltia.freenix.fr> from Ollivier Robert at "Oct 19, 97 11:32:43 pm" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Sun, 19 Oct 1997 20:43:01 -0500 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ollivier Robert said: > According to John S. Dyson: > > The VM system holds a reference. You have to do a vnode_pager_uncache when > > deleting a file. > > Wait... Isn't ufs_remove() supposed to do that ? ufs_remove() is called by > null_bypass() by an indirect call (VCALL()) and it seemed safe to consider > that the lower level was supposed to DTR. > > Do I have to create a null_remove() function in order to call > vnode_pager_uncache inside it ? > nullfs should really share the VM object with the lower filesystem, but generally what you say is true, even if you don't share the object. The complexity is one reason that I haven't fixed it. It IS fixable reasonably though. -- John dyson@freebsd.org jdyson@nc.com