Subject: Re: CVS commit: src
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 06/22/2004 10:46:28
> > > 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
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
where can i read "what Heidemann describes"?