From owner-freebsd-fs Sat Jun 9 11: 1:15 2001 Delivered-To: freebsd-fs@freebsd.org Received: from phoenix.volant.org (dickson.phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id A9AF737B401; Sat, 9 Jun 2001 11:01:08 -0700 (PDT) (envelope-from patl@Phoenix.Volant.ORG) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 158n2p-0006YQ-00; Sat, 9 Jun 2001 11:01:07 -0700 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.3+Sun/8.9.3) with SMTP id LAA10723; Sat, 9 Jun 2001 11:01:03 -0700 (PDT) From: patl@Phoenix.Volant.ORG Date: Sat, 9 Jun 2001 11:01:02 -0700 (PDT) Reply-To: patl@Phoenix.Volant.ORG Subject: Re: nullfs fixes [Was: Support for pivot_root-like system call?] To: tlambert2@mindspring.com Cc: Peter Wemm , FreeBSD-FS@FreeBSD.ORG, FreeBSD-Arch@FreeBSD.ORG In-Reply-To: <3B225E32.484672C@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 9-Jun-01 at 10:34, Terry Lambert (tlambert2@mindspring.com) wrote: > patl@Phoenix.Volant.ORG wrote: > > > > On 8-Jun-01 at 08:30, Peter Wemm (peter@wemm.org) wrote: > > > Terry, the 'cache coherency' bugs have been fixed in > > > -current for ~8 months now (September 2000). The > > > infrastructure changes for this are subject to a > > > call-for-review right now for a merge to 4.x. > > > > This is -VERY- good news. I just have two questions: > > > > 1. Which currently broken filesystems in STABLE become usable with > > these fixes? > > The fix is _my_ design. It permits the code to get the > backing object for a vm_object_t, instead of an alias. > > ... > > In answer to your question, the FS's which become usable > are the ones for which the final VP is the local media > file system, and for which there are no transformations > in the FS's layered on top of it. > > ... > > In other words, the code will work in about 1/4 of the > cases... which, however you look at it, is a hell of a > lot better than 0 of the cases, and _does_ represent > forward progress. It's just not the panacea that Peter > makes it out to be. Hmm. I would like to see a complete fix, some of the possibilities are quite interesting. BUT it sounds like this is enough to take care of my immediate need; which is for a way to setup jails with a read-only shared base filesystem (holding the system files and installed ports/packages), overlayed with a writeable per-jail tree with configuration and jail-specific data files. And to have the per-jail trees -really- be separate directories within a shared partition on the host system so that I don't have to worry about partition allocation issues. Aside from the obvious virtual hosting application, I see this setup as being quite useful for port maintainers as a tool for making it easier to determine exactly which files and directories are created or modified during an install. (Make a jail filesystem and install all the dependancies in it. Make the port. Overlay an empty directory over the jail fs. Make install. Examine the overlayed fs from outside the jail. Any files in it must have been edited or created by the install. Checking directories is slightly more work but still pretty easy.) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message