--J/dobhs11T7y2rNN
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=
rt=20
> > being present, even if they never use it,
>=20
> 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=
=20
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=
=20
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=
s,=20
> > as it lets us readily access one lock for a stack of vnodes.
>=20
> 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=
=20
v_vnlock.

> - 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=
=20
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,=
=20
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
interesting.

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFA1ziyWz+3JHUci9cRAm/SAJ4r3NPKmnGIeItWnOs+C1e9mJia2QCfbkQo
0EJwXq9DZa1Ym0YfYg5TVG0=
=7ZSr
-----END PGP SIGNATURE-----

--J/dobhs11T7y2rNN--