Subject: Re: CVS commit: src
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/21/2004 12:36:18
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 21, 2004 at 12:02:27PM +0900, YAMAMOTO Takashi wrote:
> > That 1) forces all callers to pay a (slight) penalty for snapshot suppo=
> > being present, even if they never use it,
> and transferlockers() forces all lockmgr users to pay the penalty.
I'm not fully sure why, but I'm more comfortable with this complexity in=20
the lock manager.
Also, the penalty is only a consequence of the current implementation. We=
could equally as well have code that moves sleepers (and wait channels)=20
from one lock to the other. In fact, I thought that's what it did and am a=
bit disapointed it does different. :-)
> > and 2) it destroys our ability=20
> > to use v_vnlock. v_vnlock makes life much nicer for layered file system=
> > 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=
> - 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=20
isn't used will be unionfs. And if I could figure out a way to have=20
lockmgr() calls do the locking unionfs needs, I'd do that instead. :-)
> - it violates VOP abstraction.
> sharing a lock can be achieved using locking VOPs.
It can, but the latter's slow, and can blow the kernel stack. With just=20
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.
Also, I like Heidemann's idea of the collection of vnodes (the leaf one=20
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=20
describes. A more complete one, which worked well for unionfs, would be=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----