> > > > > 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.
> 
> Every file system except unionfs is limited?

yes.
and, IMO, we should add ffs with snapshot to the list because its locking
semantics is now different from generic one.

> > > > - 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. :-)
> 
> We used to do that. We then had each file system doing almost the exact 
> same thing. We did not like that situation. So we made everything use 
> lockmgr(), and life was better. The file system locking was much more 
> maintainable, and we gained a fair bit of functionality.

almost the exact same != the exact same.

i agree that many of filesystems can share the common locking code.
however, it isn't a good reason to *force* everyone to use the same one
nor an excuse to expose it to upper layer directly.
code sharing should be done in the way like namecache(9) and genfs.

> > > > - it violates VOP abstraction.
> > > >   sharing a lock can be achieved using locking VOPs.
> > > 
> > > It can, but the latter's slow,
> > 
> > but it's clean.
> 
> Yes, and microkernels are "clean." Abstractions are good, but only when 
> they really gain you something.

of course, microkernels gain you something. :-)

in the case of vnode locking, the abstraction allows
filesystem implementations to use different locking.

> I guess another part of my experience with this is that I made dmfs, the 
> data migration file system. In it, the ability to directly & quickly 
> change lock state was very useful.

function call overheads for locking VOPs were one of bottlenecks of dmfs?
it sounds very weird to me.

> > > 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.
> 
> I don't look at it as a cheat. I look at it as a requirement that file 
> systems do real, hard-core locking. And given the state of things when I 
> started, that was a very good thing.

why do you think that exposing a lock is a requirement?
i can see that it has some benefits.  but it isn't a requirement at all.
it's exactly a cheat for speed.

> > where can i read "what Heidemann describes"?
> 
> That would be his disseration. 
> http://www.isi.edu/~johnh/PAPERS/Heidemann95a.html

thanks.

YAMAMOTO Takashi