Subject: Re: CVS commit: src
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 06/22/2004 15:13:59
> > > > > 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?
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.