Date: Thu, 26 Apr 2007 10:36:02 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Greg Troxel <gdt@ir.bbn.com> Cc: freebsd-fs@freebsd.org Subject: Re: distributed filesystems Message-ID: <20070426103214.X37507@fledge.watson.org> In-Reply-To: <rmibqhc182r.fsf@fnord.ir.bbn.com> References: <20070422124731.GA20548@harmless.hu> <rmiy7kjs3o5.fsf@fnord.ir.bbn.com> <462CAE66.3050001@freebsd.org> <rmi1wibrxs2.fsf@fnord.ir.bbn.com> <20070425093131.F37507@fledge.watson.org> <rmibqhc182r.fsf@fnord.ir.bbn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070426103214.X37507>