Re: HEADS UP: Any umapfs users!

On Mar 29, 2004, at 6:45 PM, Peter Wemm wrote:

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


I don't think there's any need to bandaid this filesystem Peter. All it
needs is an all inspiring kernel hacker to step forward and do the
work. That being said, if all the CS students haven't already been 
scared
off by the FreeBSD development team. :-) I'd estimate this would take
some that is looking for a good introduction to a part of the filesystem
code about a day.

Just take a snapshot of nullfs and copy it over and change it to use the
underlying vmobject_t's directly via VOP_GETVOJECT. This works
because there's no associated data with the upper vnode layer that's
not present in the lower vnode layer. The stat information can be made
to be reverse translated and passed back up because the credentials
can just be crdup/cdmod down.

-DR