From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 05:56:27 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 E8D8B16A4F0 for ; Tue, 30 Mar 2004 05:56:27 -0800 (PST) Received: from imf19aec.mail.bellsouth.net (imf19aec.mail.bellsouth.net [205.152.59.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E70743D3F for ; Tue, 30 Mar 2004 05:56:27 -0800 (PST) (envelope-from drhodus@machdep.com) Received: from [192.168.1.93] ([68.209.168.6]) by imf19aec.mail.bellsouth.netESMTP <20040330135627.URYG1775.imf19aec.mail.bellsouth.net@[192.168.1.93]>; Tue, 30 Mar 2004 08:56:27 -0500 In-Reply-To: <200403291545.06797.peter@wemm.org> References: <200403291545.06797.peter@wemm.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <08BE20C6-8252-11D8-85F0-00039380DD2C@machdep.com> Content-Transfer-Encoding: 7bit From: David Rhodus Date: Tue, 30 Mar 2004 08:56:25 -0500 To: Peter Wemm X-Mailer: Apple Mail (2.613) X-Mailman-Approved-At: Wed, 31 Mar 2004 04:37:13 -0800 cc: current@freebsd.org Subject: Re: 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: Tue, 30 Mar 2004 13:56:28 -0000 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