distributed filesystems

[Robert Watson]

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