From owner-cvs-all@FreeBSD.ORG Wed Jun 18 03:03:29 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC09137B401; Wed, 18 Jun 2003 03:03:29 -0700 (PDT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5998843FCB; Wed, 18 Jun 2003 03:03:29 -0700 (PDT) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au (210.50.219.19) by smtp01.syd.iprimus.net.au (7.0.015) id 3EED7FDA001034AC; Wed, 18 Jun 2003 20:03:28 +1000 Received: by dilbert.robbins.dropbear.id.au (Postfix, from userid 1000) id E8DF1C91F; Wed, 18 Jun 2003 20:03:25 +1000 (EST) Date: Wed, 18 Jun 2003 20:03:25 +1000 From: "Tim J. Robbins" To: Pawel Jakub Dawidek Message-ID: <20030618200325.A3179@dilbert.robbins.dropbear.id.au> References: <200306170852.h5H8qjgg087299@repoman.freebsd.org> <20030617133130.GF38547@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030617133130.GF38547@garage.freebsd.pl>; from nick@garage.freebsd.pl on Tue, Jun 17, 2003 at 03:31:30PM +0200 cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2003 10:03:30 -0000 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. Tim