Date: Wed, 18 Jun 2003 20:03:25 +1000 From: "Tim J. Robbins" <tjr@FreeBSD.org> To: Pawel Jakub Dawidek <nick@garage.freebsd.pl> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c Message-ID: <20030618200325.A3179@dilbert.robbins.dropbear.id.au> In-Reply-To: <20030617133130.GF38547@garage.freebsd.pl>; from nick@garage.freebsd.pl on Tue, Jun 17, 2003 at 03:31:30PM %2B0200 References: <200306170852.h5H8qjgg087299@repoman.freebsd.org> <20030617133130.GF38547@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030618200325.A3179>