cvs commit: src/sys/fs/nullfs null.h null_subr.c null_vnops.c

[Dmitry Sivachenko]

On Wed, Jun 18, 2003 at 08:03:25PM +1000, 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


BTW, what is the reason for creating these clone vnodes?
Why we can't simply return the original vnode?


> 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.
>