Subject: Re: CVS commit: src
To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: tech-kern
Date: 06/21/2004 12:36:18
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)