Date: Mon, 29 Mar 2004 15:45:06 -0800 From: Peter Wemm <peter@wemm.org> To: current@freebsd.org Subject: HEADS UP: Any umapfs users! Message-ID: <200403291545.06797.peter@wemm.org>
next in thread | raw e-mail | index | archive | help
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@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403291545.06797.peter>