From owner-cvs-src@FreeBSD.ORG Thu Jun 19 00:58:29 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41E6837B401; Thu, 19 Jun 2003 00:58:29 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 541B743FDD; Thu, 19 Jun 2003 00:58:28 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h5J7wQJa080190; Thu, 19 Jun 2003 00:58:26 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h5J7wPte080189; Thu, 19 Jun 2003 00:58:25 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 19 Jun 2003 00:58:25 -0700 From: David Schultz To: "Tim J. Robbins" Message-ID: <20030619075825.GB79448@HAL9000.homeunix.com> Mail-Followup-To: "Tim J. Robbins" , Pawel Jakub Dawidek , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org References: <200306170852.h5H8qjgg087299@repoman.freebsd.org> <20030617133130.GF38547@garage.freebsd.pl> <20030618200325.A3179@dilbert.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030618200325.A3179@dilbert.robbins.dropbear.id.au> cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG cc: cvs-src@FreeBSD.ORG Subject: Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 07:58:29 -0000 On Wed, Jun 18, 2003, Tim J. Robbins wrote: > On Tue, Jun 17, 2003 at 03:31:30PM +0200, Pawel Jakub Dawidek wrote: > > > Great work! > > > > You susspect there are more problems with nullfs? > > This file system looks like a very simple thing, maybe it's implementation > > is too complicate? > > > > I'm not sure, but if we forgot about mount flags, etc. (something like > > hardlink to directory) we only have to do one thing: return correct vnode on: > > > > # cd /mnt/null/.. > > > > Every other operation inside nullfs should be done with functions from > > original file system. > > > > Maybe I'm talking stupid things here, but those two file systems are really > > helpfull (I'm talking also about unionfs) and it will be great if there > > will be no BUGS section in manuals for those file systems. > > The main problems with nullfs seem to be locking and trying to create clones > of the lower vnode (wrt. the VM system and special files). Once kern/51583 > is fixed and I've stress-tested nullfs a bit more, I'll probably be confident > enough in it to remove the BUGS section. I can't really comment on unionfs... > I plan to test it out soon and see whether any of the recent nullfs bugfixes > could apply to it, esp. the deadlock one. unionfs has the same problems, plus some extra issues with directories and whiteouts. See the recent discussion on current@ regarding one such issue. If you solve any problems for nullfs that happen to have analogues in unionfs, I'm sure it would be appreciated if you found the time to port the fixes.