From owner-freebsd-fs@FreeBSD.ORG Thu Apr 26 09:36:03 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 311AC16A402; Thu, 26 Apr 2007 09:36:03 +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 05EAA13C468; Thu, 26 Apr 2007 09:36:02 +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 96FA34760D; Thu, 26 Apr 2007 05:36:02 -0400 (EDT) Date: Thu, 26 Apr 2007 10:36:02 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Greg Troxel In-Reply-To: Message-ID: <20070426103214.X37507@fledge.watson.org> References: <20070422124731.GA20548@harmless.hu> <462CAE66.3050001@freebsd.org> <20070425093131.F37507@fledge.watson.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: Thu, 26 Apr 2007 09:36:03 -0000 On Wed, 25 Apr 2007, Greg Troxel wrote: > Good point, and I suspect it isn't that hard. NetBSD is also (finally) > moving to fine-grained locking. Given what a long, hard haul that proved for every other operating system thas has approached the project, I would expect to see results from that project in the longer, rather than shorter, term. > I supsect one could either create a coda lock and always grab that, or to > make locks for each data object (the name cache is probably what's needed - > everything else is per-vnode and the vnode lock protects most vnode > changes). Up-front, I think a global Coda lock protecting things like message queueing and waiting structures would be fine. Since most vnode operations pass straight through to the container vnode (or did, when I last worked on Coda), it could be that no additional locking is required on things like read/write paths beyond the existing vnode locking. Any chance you'd have interest in working on this project? :-) While the time is not yet here, there will come a point where we will be interested in kicking out file systems that cannot operate without Giant, in the same way we're now doing that for network stack components. There's a significant complexity overhead to all the conditional per-filesystem giant acquisition logic, but it means all file systems will need to be updated. Robert N M Watson Computer Laboratory University of Cambridge