> > > and 2) it destroys our ability 
> > > to use v_vnlock. v_vnlock makes life much nicer for layered file systems, 
> > > as it lets us readily access one lock for a stack of vnodes.
> > 
> > i think that it's better to remove v_vnlock because:
> > - it's only useful in the limited cases.
> 
> Let's see. Layered file systems and snapshots. They both make good use of 
> v_vnlock.

layered filesystems can use it only when it uses 1:1 vnode mapping and
the underlying filesystem uses lockmgr to implement vnode lock and
the lock is exported.  it's very limited.

> > - it involves complexity in layered filesystems
> >   as they should deal with two cases. (exported and not exported)
> 
> The exported case is the greatly prefered one. The only case where it 
> isn't used will be unionfs. And if I could figure out a way to have 
> lockmgr() calls do the locking unionfs needs, I'd do that instead. :-)

IMO, locking should be left to each filesystem implementations.
it's a bad idea to force everybody to use the same one.
(esp. when it's lockmgr. :-)

> > - it violates VOP abstraction.
> >   sharing a lock can be achieved using locking VOPs.
> 
> It can, but the latter's slow,

but it's clean.

> and can blow the kernel stack. With just 
> one or two layers, it doesn't make that much difference. But with some of 
> the multi-layer ideas Heidemann had, we can get may more layers.

locking VOPs are not likely the most stack-consuming VOPs.
cheating only for them doesn't make much sense.

> Also, I like Heidemann's idea of the collection of vnodes (the leaf one 
> and the ones over it) acting as an aggregate object. One object, one lock, 
> v_vnlock points to it.
> 
> I admit that v_vnlock is only a partial implementation of what Heidemann 
> describes. A more complete one, which worked well for unionfs, would be 
> interesting.

where can i read "what Heidemann describes"?

YAMAMOTO Takashi