On Tue, Jun 17, 2003 at 01:52:45AM -0700, Tim J. Robbins wrote:
+> tjr 2003/06/17 01:52:45 PDT
+> FreeBSD src repository
+> Modified files:
+> sys/fs/nullfs null.h null_subr.c null_vnops.c
+> MFp4: Fix two bugs causing possible deadlocks or panics, and one nit:
+> - Emulate lock draining (LK_DRAIN) in null_lock() to avoid deadlocks
+> when the vnode is being recycled.
+> - Don't allow null_nodeget() to return a nullfs vnode from the wrong
+> mount when multiple nullfs's are mounted. It's unclear why these checks
+> were removed in null_subr.c 1.35, but they are definitely necessary.
+> Without the checks, trying to unmount a nullfs mount will erroneously
+> return EBUSY, and forcibly unmounting with -f will cause a panic.
+> - Bump LOG2_SIZEVNODE up to 8, since vnodes are >256 bytes now. The old
+> value (7) didn't cause any problems, but made the hash algorithm
+> These changes fix nullfs enough that a parallel buildworld succeeds.
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.
Pawel Jakub Dawidek firstname.lastname@example.org
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net