From owner-freebsd-fs Thu Feb 22 14:15:34 2001 Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 3E58237B401 for ; Thu, 22 Feb 2001 14:15:31 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id PAA20561; Thu, 22 Feb 2001 15:12:24 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAAviaagO; Thu Feb 22 15:12:17 2001 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA26750; Thu, 22 Feb 2001 15:15:19 -0700 (MST) From: Terry Lambert Message-Id: <200102222215.PAA26750@usr05.primenet.com> Subject: Re: Status of nullfs To: patl@phoenix.volant.org (Pat Lashley) Date: Thu, 22 Feb 2001 22:14:48 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: from "Pat Lashley" at Feb 22, 2001 01:38:40 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The man page in -STABLE for mount_null contains dire warnings about > its lack of support and potential to cause problems. But how > solid/shakey is it really? Is it, in practice, safe to use? Is > there any particular usage that is more likely to cause problems, > or are the warnings just there because nobody is actively keeping > it up to date? > > In other words, if I'm willing to take the risk of using it, just > how big of a risk am I actually taking? Any mmap'ed writes will fail due to cache coherency problems. If the system isn't quiescent long enough to flush everything out before an unmount, you can panic. If you have exposed the NULL mount , e.g. by mounting an FS on /usr, and then nullfs mounting it to /null_usr, then modifications to the /usr FS will not result in coherency notification, and files will become corrupt, if accessed both ways. Paging from executables can cause problems for multiple copies of executables, if statically initialized data is modified (copy on write) due to the way backing page handling is limited. All of these derive from the fact that the vnode in the upper layer (nullfs) and the vnode in the lower layer (ffs or whatever) have seperate vm_object_t's, even though the data contents of the file are supposed to be treated as identical for both. There are a number of patches to manually enforce coherency; as far as I know, they don't deal with the pager path, and, since the coherency is explicit, the /usr vs. /null_usr problem is not resolved. Check the list archives to obtain the patches. If you need stacking for a project, FiST has been ported to FreeBSD. Personally, I have not used it, but supposedly it addresses the vm_object_t aliasing caused coherency problems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message