From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 15:45:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D868B16A4CF for ; Mon, 29 Mar 2004 15:45:11 -0800 (PST) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id C670B43D46 for ; Mon, 29 Mar 2004 15:45:07 -0800 (PST) (envelope-from peter@yahoo-inc.com) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id 1B059881F; Mon, 29 Mar 2004 15:45:07 -0800 (PST) From: Peter Wemm To: current@freebsd.org Date: Mon, 29 Mar 2004 15:45:06 -0800 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200403291545.06797.peter@wemm.org> Subject: HEADS UP: Any umapfs users! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2004 23:45:12 -0000 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