HEADS UP: Any umapfs users!

[Peter Wemm]

I've just (slightly) pulled the rug out from underneath umapfs.  It is 
easy to bandaid to make it compile etc, but that doesn't solve the 
serious fundamental problems inside.  Basically, it has been suffering
from about 5 years of neglect in the tree, and is totally out of sync 
with the vnode locking protocol.

The problems are nasty.  For starters, it has no vnode locking 
implementation.  It used to have a stub "NOP" shim that stopped 
insta-panics for a while.  However, the moment that a vnode is 
reclaimed and goes inactive, we're guaranteed of a deadlock when it 
calls vop_inactive on the underlying filesystem.  (Or so I understand 
from what Tim Robbins (tjr@) told me).

For it to live on, it needs a caretaker who can go back and duplicate 
the last 5 years worth of development that has been done to its 
ancestor, nullfs.  (umapfs is loosely derived from nullfs).  It needs 
real vnode locking - this is critical these days.  It needs to be able 
to survive in a full DEBUG_VFS_LOCKS kernel.  Adding a bandaid is wrong 
because it just takes it further in the wrong direction.

Any takers?  Read fs/nullfs/null_vnops.c::null_lock() and friends before 
you say yes.
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5