From owner-freebsd-fs@FreeBSD.ORG Wed Apr 25 08:35:20 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 659D316A400 for ; Wed, 25 Apr 2007 08:35:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 34B0D13C448 for ; Wed, 25 Apr 2007 08:35:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8A97746EBE; Wed, 25 Apr 2007 04:35:19 -0400 (EDT) Date: Wed, 25 Apr 2007 09:35:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Greg Troxel In-Reply-To: Message-ID: <20070425093131.F37507@fledge.watson.org> References: <20070422124731.GA20548@harmless.hu> <462CAE66.3050001@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: distributed filesystems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2007 08:35:20 -0000 On Mon, 23 Apr 2007, Greg Troxel wrote: > Big issues that I think you'll run into when porting the NetBSD version to > FreeBSD are: > > vnode locking rules are different. NetBSD's rules have been > regularized, with lookup taking a locked dvp and returning a locked > vpp, leaving dvp locked, and fairly consistent vput for leaf > operations. > > NetBSD has UVM, and so the interface to getpages/putpages > is probably different. Coda passes a file by dev/ino into the kernel > and then vnode ops on the coda vnode get forwarded to the (ffs) > container file. This is tricky for handling page faults for executing > a program, as the vnode isn't open. And issue three, which can't be ignored: FreeBSD now runs its VFS and some file systems without the Giant lock (MPSAFE). Any significant new file system work for a file system must be done without the Giant lock in order to achieve necessary scalability. Removing the Giant lock from Coda shouldn't be all that hard, since the set of internal data structures is relatively small, but it will need to happen if Coda support is going to remain in the FreeBSD kernel in the long term. Certainly, we wouldn't accept it as a new file system at this point if it required the Giant lock. The Coda module in FreeBSD has been essentially unmaintained for about six to eight years; tjr did some minor maintenance and fixing along the way to keep it working, but it needs a dedicated maintainer to perform code updates, handle locking issues, etc. Robert N M Watson Computer Laboratory University of Cambridge