Date: Tue, 30 Mar 2004 08:56:25 -0500 From: David Rhodus <drhodus@machdep.com> To: Peter Wemm <peter@wemm.org> Cc: current@freebsd.org Subject: Re: HEADS UP: Any umapfs users! Message-ID: <08BE20C6-8252-11D8-85F0-00039380DD2C@machdep.com> In-Reply-To: <200403291545.06797.peter@wemm.org> References: <200403291545.06797.peter@wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08BE20C6-8252-11D8-85F0-00039380DD2C>